This is the argument that the starting routine takes. If the function’s return type is void *, then its name is simply written otherwise, it has to be type-cast to void *. The name of the function that the thread starts to execute. Used to set the attributes of a thread(e.g., the stack size, scheduling policy, etc.) Passing NULL suffices for most applications. Reference (or pointer) to the ID of the thread. For multiple threads, an array can be created where each element is an ID for a separate thread: pthread_t id Ī thread is created and starts using the function pthread_create(). The same pthread_t object cannot be used by multiple threads simultaneously. #include Įach thread has an object of type pthread_t associated with it that tells its ID. Each thread can execute part of the same task (e.g., summing elements of an array), or it can allocate the same task for different clients in a client-server architecture. The latest Java, for example, has a 'ForkAndWait' threadpool class that should do exactly this kind of stuff, but C++, (or even C#, if you're into serfdom), is better than plain C.A program can be quickly executed by introducing concurrency using threads.
I have to add that operations like this are a huge pile easier in an OO language. It's not that difficult to arrange it so that the assembly of the contexts and the synchro waiting is done in a task as well, so allowing the pool to process multiple 'ForkAndWait' operations at once for multiple requesting threads. If a thread decrements it to zero, is signals the the event/condvar/semaphore and the originating thread runs on, knowing that all the tasks are done. In OnComplete, the threads atomically count down taskCount. When done, the threads call the 'OnComplete' function pointer. The four threads get a context from the P-C queue and work away. Then it submits all four contexts to the queue, atomically incrementing a a taskCount up to 4 as it does so, and waits on an event/condvar/semaphore. The thread that wants to queue the four tasks assembles the four context structs containing, as well as all the other data stuff, a function pointer to an 'OnComplete' func. One producer-consumer thread with 4 threads hanging off it. Only then, if your profiler tells you that you spend a substantial amount of time in the pthread routines, start thinking of implementing (or using) a worker pool to recycle your threads. Once you have such an implementation for your task, measure. The only thing that would be important if you have your workers communicate through shared variables, mutexes etc (and not via the return value of the thread) is that you start your threads detached, by using the attribute parameter to pthread_create. Mondern implementations of POSIX threads are efficient enough that they support the creation of a lot of threads, really a lot, and the overhead is not prohibitive. If the work that your threads are doing is a substantial computation (say at least a CPU second or so) such a scheme is a complete overkill.
What you are trying to implement is a worker pool, I guess, there should be a lot of implementations out there.
PTHREAD C 3 CODE
If there is a need, I can post a simplified version of my code to show what I am trying to do(even though I think that my approach is flawed!).Ĭan you please give me any insights into how this scenario can be implemented using pthreads?Īs far what can be seen from your description, there seems to be nothing wrong with the principle. It will be very helpful to know how this can be implemented. My guess is that, the way I have coded it, I have over-complicated the scenario. I have written the code but it is just running indefinitely and I cannot figure out why. I know that this can be done using pthread_cond_wait, pthread_Cond_signal. I am a Masters research student and I am encountering the need for the above scenario. If the parent thread receives a kill command (assume a specific kind of data), it indicates to all the sub-threads and they terminate themselves. If the parent thread gets more data the above process is repeated - albeit with the already created 4 threads. Now it waits for new data(the sub-threads are not killed yet, they are just waiting). Once the parent thread knows that all these sub-threads have completed this round, it computes the global output and prints it out. Once these sub-threads have done executing, they will set the output in their corresponding context variables and wait(for reuse). The sub-threads have to process this data and in the mean time the parent thread should wait on these threads. When the parent thread gets data, it will set split the data and assign it to 4 seperate context variables - one for each sub-thread. I have a parent thread which needs to create 4 child threads with id 0, 1, 2, 3.
0 kommentar(er)
