Wallis's estimation is based on: Note that the numerator goes up by two on every other factor; the denominator does as well, but on the "other every other factor. After iterating about 20,000 times it generates an answer somewhere around the "real" value of 3.1415926535 A second method (T'm not sure where it came from) is to calculate it this way: /4= 1-1/3 + 1/5-1/7 + 1/9-1/11 + 1/13-1/15 We want to calculate using the above two methods, but to separate the workload into multiple program threads. You must write this program in either "C" or "C+". Use POSIX threads to divide the work into eight executing functions to calculate the first way. Wait for the threads to all finish, then start eight new threads to calculate second way Each function will calculate 1/8th of the workload. For example (first way) thread 0 can calculate numbers for iteration 0, 8, 16, 24, which corresponds to 2/1, 10/9, 18/17, 26/25, and so on. In general, add eight to the numerator each loop, add eight to the denominator each loop. Thread 1 can calculate numbers for 1, 9, 17, which corresponds to 2/3, 10/11, 18/19, and so forth. Same idea for threads two through severn In general, have each of the eight threads calculate 1/8th of the result by skipping ahead eight divisions in the above series. You can see that the second way is similar, and I will leave that to you Bring in the POSIX thread library by using the "-lpthread" command line argument to the compiler Use the "C C+type "double" for all of the calculations, not just "float" I want the "C" "C++code and a "Makefile" which recompiles the code. . In both cases, have one global variable which maintains the current calculation product. This global variable is thus available for each thread. Start each thread with a parameter to tell it which thread it is Start them in a small for-loop or eight lines of code, so that they all start as close together in time as possible. You will need to coordinate multiplying (adding) into the global value for . Presumably there's two ways to do this-have the threads calculate, individually, their products (sums) and at the end multiply (add) all of these together. Or... Have the threads lock a mutex, put the intermediate result into the running calculation, and then unlock the mutex I want you to do a mixture of these, for both methods, where each thread calculates ten terms on its own and then locks the mutex, updates the running answer, and unlocks. Each thread should calculate 25,000 values; since there are eight threads we will calculate and multiply in a total of 200,000 factors. Each thread would be locking and unlocking 2500 times As you may have figured out by now, the actual calculation is not the point of the exercise learning how to program with threads is the point of the exercise. I think that is pretty well calculated by others besides us... The output should be the calculated value and the difference between your value and the established value for t, with 15 digits of precision. Something like this: A11 threads done, value calculated to 3.14159261432049 This is off by about -0.00000003926930 The include file has a definition for #define MP1 3.14159265358979323846 Let's use that. Lastly, note that the program if it is operating correctly will not give you the same result each time you run it! The timing of combining the intermediate results will slightly impact the math. If you are getting the exact same answer each time you're probably doing something wrong