Reference no: EM13347766

Create a multi-threaded competition in which opposing Robin Hoods will attack one another and try to take each other's gold coins. Occasionally, they will donate some of their winnings to the community. To simulate the attack, each Robin Hood will be assigned a Band of Merry Men (or Women) with which he (or she) can do battle. When given the chance, Robin will challenge as many other competitors as possible. If he is victorious, he will then take some share of the gold coins of the loser. Robin will enter combat by: (1) randomly selecting one of his enemies as a target, (2) selecting a random percentage of his gold coins as a wager, and (3) selecting a random number of his merry folk to do battle. Victory always goes to the competitor who brings the most soldiers into battle.

    So how does this work? As you may have guessed, each of our Robin Hoods is represented by a thread. Each thread operates independently from the others. (i.e., it will be scheduled independently). That being said, the threads will have to share data in some fashion. While there are a number of ways that this process could be represented, you will do so by providing a "challenge" list for each competitor. As challenges are issued they will be placed into a list assigned to a specific Robin/thread. A challenge would consist of the (i) challengers ID (ii) the number of soldiers sent by the challenger (iii) the amount of the wager. When the target thread receives CPU control, it will be able to read from that list and respond to the challenge. It does so by first checking to see if it has enough money to match the wager. If not, this Robin/thread automatically loses and all his money goes to the challenger. If he does have enough money, he will select a random number of his own men and then compare this to the number provided by the challenger. The winner gets the appropriate number of gold coins from the loser (in a tie, nobody wins).

 Of course, Robin wouldn't be a hero if he didn't donate some of his winnings to the poor. Therefore, after every ten victories, Robin selects 10% of his current wealth and donates it to a community fund (the amount should be rounded to the nearest dollar so that we only work with integers). He may make many such contributions as the competition is running. It must be possible to keep track of everyone's contributions since the "winner" will ultimately be the most generous Robin.

    There are a few other details that need clarification. First, if the counts of coins and soldiers are purely random, then this would produce a sort of stalemate. In other words, every Robin would win about as much as he loses. Real life isn't like this so we will make some Robins a little better than others. To do this, we will vary the size of the Merry Men. Specifically, each Robin/thread gets one more soldier than the preceding Robin. So Thread 1 has one soldier, Thread 2 has two soldiers, ...Thread n has n soldiers. What this means is that, over time, a winner would actually emerge. That being said, the randomness in the challenge process allows some upsets. For example, Thread 100 could wager 100% of its coins but send just 2 soldiers to do battle with Thread 4, who sends 3 soldiers. Thread 100 would lose and be out of the game. In general, though, higher numbered threads should do a lot better.

    We also need a mechanism to provide basic parameters to the game. We will do this through some simple command line parameters. Assuming that the application is called RobinHoods, an invocation might look like this:

The parms thread_count, iteration_count, and coin_count are all integers. thread_count should be a number between 2 and 10. iteration_count can be a number between 1 and 100 million. And coin_count can be a number between 10 and 1 million.

    So, to recap, the idea is as follows. You will accept the arguments passed to the application at run time. A summary of these parms will be be printed immediately to the console, along with the total number of coins available (i.e., thread_count * coin_count). You will then generate thread_count threads, and each will compete when it gets the CPU. It will do so by generating iteration_count challenges, using a simple looping mechanism. However, before each individual challenge is generated, the thread must check its own challenge queue. If it is not empty, it must process all challenges that have been placed there by other Robins/threads. In other words, it must adjust the two coins counts as necessary (i.e., winner and loser). Only then does it continue with the loop. Each time ten victories have been recorded, Robin donates 10% of his current total to charity. If Robin runs out of money, however, a notice must be printed immediately to the console and the thread should no longer participate in the competition.

    Once the iterations are completed, and ALL challenge lists are empty, the main thread will summarize the results and print the results to the console. In short, it should order the Robins from most to least successful, in terms of the number of coins donated to charity. You should also list the coins still owned by each Robin (i.e., not donated). Finally, you should provide the total of all donated coins, plus the total of all coins still possessed by the remaining Robins. If your threads cooperated properly, this total should be the same as the number of coins available at the beginning of the process.

Below, a sample output is listed
Total competitors: 8
Total challenge iterations: 10000
Individual coin count: 1000
Total coins available: 8 * 1000 = 8000
...
Robin 1 has run out of money
...
Robin 3 has run out of money
...
Robin 2 has run out of money
...

Coins donated:

Robin 8: 4250 (755 remaining)

Robin 7: 2411 (416 remaining)

Robin 5: 156 (12 remaining)

Robin 3: broke

Robin 6: broke

Robin 4: broke

Robin 1: broke

Robin 2: broke

Total coins in circulation: 6817 donated + 1183 remaining = 8000