Threads are creating using the GThread_create function. The three parameters specified there should be self explanatory. There should be no pre-set limit in your gthreads regarding how many threads can be created, so don't pre-allocate some fixed amount of space for handling threads, instead use a linked list of "Thread Control Block" pointers. See my sample program on how to manage a singly linked list here. Also, "create" does NOT schedule the thread immediately! It just creates it, and it is scheduled later when a thread is being pre-empted or the current thread is yielding.
Threads may call "GThread_yield" to voluntarily give up the CPU to another thread. The code for yield should just select another ready thread and transfer control to that thread at the last point in it's execution path.
Threads MUST call GThread_exit before terminating. This actually makes our job a bit easier, since you don't have to worry about what to do if a thread's "StartFunc" just exits (which pthreads allows).
You should maintain a count of active threads, and return that count in response to a "GThread_count" call. The testgt.c program will use this extensively to know when all threads have completed.
One other important point. The main program is also a thread, and should be scheduled just like all the other threads. In other words, I expect the main program of testgt.c to be pre-empted just like any other thread, and it may also call GThread_yield to yield.
GTMutex_create is called to initialize a mutex to the default "unlocked" value. GT_MUTEX is defined as a void* in gthreads.h, but of course you will make a structure of you own choosing to use for mutexes, and do a type cast to the right type.
GTMutex_lock and GTMutex_unlock should be self-explanatory. However, to make it more interesting, we specify the following two requirements. DO NOT SPIN waiting for a lock to free up. Instead, if a thread asks for a lock that is not available, de-schedule that thread, making a note of the mutex that it is waiting on. When the mutex is freed, re-schedule that thread (you can either schedule it immediately, or note that it is a candidate for later scheduling). Second, we will require that only the thread that locked a mutex can unlock it. In other words, if any thread other than the one that locked a mutex tries to unlock it, do not unlock it and return GT_FAILED instead.
For each mutex, keep track of the successful and unsuccessful lock attempts. testgt.c will use these values to insure things are working right.
To implement the Mutex, use the Sparc "swap" instuction. It's easy to include a small piece of assembly language code in your C program using the "asm" macro. Here is a sample program that shows how to do this.
| Test 1, GThread_yield testing | 30% |
| Test 2, Pre-emptive Multitasking testing | 30% |
| Test 3, Proper operation and scheduling of Mutexes | 20% |
| Test 4, Proper ownership tracking of Mutexes | 10% |
| Quality of Code (Neatness, commenting, CLEAN COMPILE) | 10% |
Instructions for creating a shar file are as follows:
Login to a unix machine. I am using "elvis.cc.gatech.edu" as the example
here.
Type "shar files > sharfilename" where files is the list of the files
that you
are going to submit and sharfilename is the name of the shar file you
re going
to create. Make sure to mention how to deal with these files in your
README file.
Make sure that you do NOT include any binaries in your shar files. I
am going
to compile your programs from scratch. If you have any special commands
needed
to compile your code then mention them in your README file.
You can email a shar file to the cs6210 account by doing:
mail cs6210@cc.gatech.edu < project2.shar
Assignments will not be accepted late without a very good sob story
and the
proper papers filled out in triplicate :)