Download Pthreads - Assignment 2 | Parallel Programming | CSCI 4320 and more Assignments Computer Science in PDF only on Docsity!
CSCI-4320/6340 Assignment 2: Pthreads
Christopher D. Carothers
Department of Computer Science
Rensselaer Polytechnic Institute
110 8th Street
Troy, New York U.S.A. 12180-
February 27, 2009
DUE DATE: 12 p.m/Noon, Tuesday, March 17th
1 Description
For this assignment you will creating a Pthread program that sends messages between proces- sors using shared memory on the Intel Medium Memory SMP – ims01 upto 64 processors and compare the performance of your implementation to an equivalent MPI program that executes on the Blue Gene/L supercomputer located in the CCNI for the same processor counts. The specifics are as follows:
- Your shared memory Pthread program will execute on 1, 2, 4, 8, 16, 32 and 64 processor configurations creating as many threads as processors for the particular configuration. Do not have thread 0 be a “join” thread. Create N-1 threads.
- Each thread/processor has an initial set of 16 messages of a pre-defined size. The sizes can range from 64 bytes, 256 bytes, 1024 bytes and 4096 bytes plus a static header which is defined below.
- Each thread executes a scheduler functions. At start-up, each thread will take the initial set of messages and randomly pick another thread as the destination. Note, I’ll let you know soon what random number generator to use on the Blue Gene.
- Once the initial messages are sent, each thread asynchronously empties its recv queue and INCREMENTS the sent count on the message. When a message’s sent count
is 163840 , then you can delete that message from the system. Otherwise, randomly pick another processor/thread as a destination and schedule the message for that processor/thread. When all messages have been remove from the system – that is all threads have no more work
- the Pthread program should terminate.
2 Pthread Implementation Hints
For this assignment, I suggest you architect it in the following way.
- Create a processor t data structure which contains the necessary recv queue lock and recv queue list. Then allocate a global array of this data structure, one for each thread. Do this before your create any threads. Make sure to initialize all mutex locks and other elements of the data structure.
- When you create your threads, use the index variable in the creation loop as the thread id and pass that as an argument to the scheduler function, which is the primary entry point into the thread. This parameter is your thread id and you can use it to index into a threads own processor t data structure. Thus, each thread has it’s own specific processor t data structure which you’ll schedule messages to be sent via locking the mutex lock and inserting the message into that threads recv queue list of the destination thread/processor. You can write your own send function that does this. Likewise a recv function will pull events from your own local recv queue list. Do not forget to lock the queue list for both sends and recvs. Also, use the pthread mutex trylock for better performance.
- For each thread, once inside the scheduler function, allocate your message t data structures using malloc or calloc system calls. Note, they will have a header part which consist of the send count and a next pointer for placing on the linked list recv queue and a data part which is just a dummy array of char based on the size of the message. One the allocation is complete send your initial messages.
- Efficient Termination. This is harder than you think. Basically, you want to know when all the threads have no more work/messages, but you don’t want to use a barrier syn- chronization after each message send. But there are some interesting cases for you to con- sider. Suppose Thread A sends its last message to Thread B and sets a globally visible empty flag. Next, suppose Thread B was already empty of work and has set its globally visible empty flag and sees Thread A’s empty flag is now set. So, it would think,
// typedef unsigned long long int unsigned long long;
static inline unsigned long long rdtsc(void) { unsigned hi, lo; asm volatile ("rdtsc" : "=a"(lo), "=d"(hi)); return ( (unsigned long long)lo)|( ((unsigned long long)hi)<<32 ); }
#elif defined(powerpc)
// typedef unsigned long long int unsigned long long;
static inline unsigned long long rdtsc(void) { unsigned long long int result=0; unsigned long int upper, lower,tmp; asm volatile( "0: \n" "\tmftbu %0 \n" "\tmftb %1 \n" "\tmftbu %2 \n" "\tcmpw %2,%0 \n" "\tbne 0b \n" : "=r"(upper),"=r"(lower),"=r"(tmp) ); result = upper; result = result<<32; result = result|lower;
return(result); }
#else
#error "No tick counter is available!"
#endif
#endif
Use the above macro rdtsc. To do things like:
unsigned long long start_time = 0; unsigned long long finish_time = 0; unsigned long long total_time = 0;
rdtsc( start_time );
for( i; i < MAX_WHATEVER; i++ ) { DO TEST }
rdtsc( finish_time );
total_time = finish_time - start_time;
Note, I’ll place a copy of of this in rdtsc.h on the Class website for you to download.
5 Experiments and Write-up
You will conduct a series of experiments on both platforms where you are to collect execution times and graph your results across all runs. In particular, there are 7 processor configurations and 4 messages sizes for a total of 28 experiments. You should graph each group of processors within a fixed message for the Blue Gene and the Intel SMP system. That is you’ll have two plots per graph where the y-axis is the execution time and the x-axis is the processor count. In total you’ll have four graphs, one for each message size. Along with the graphs, please include a write-up which describes your Pthread solution why you observed the particular performance phenomena that is shown in your graphs.
6 Hand-In Instructions
Place your code in your area51 account. Please bring a hard copy of your performance report with graphs to class.
