On 3/15/07, Sreevathsa <sreevathsa@xxxxxxxxx> wrote:
I have a question on syncing the threads. I have a scenario like this:
5 threads (T1, T2, T3, T4 & T5) are working on this piece of code:
LINE1: for(;;) {
LINE2: pthread_mutex_lock(&r1_mutex)
LINE3: .............
LINE4: .............
LINE5: pthread_mutex_unlock(&r1_mutex)
/* some code that does not need protection */
LINE6: .............
LINE7: .............
LINE8: pthread_mutex_lock(&r2_mutex)
LINE9: .............
LINE10: .............
LINE11: pthread_mutex_unlock(&r2_mutex)
LINE12: }
r1_mutex is to protect the access to a FIFO queue. I want the 5 threads to
process the queue contents in the same order in which they arrived into the
queue.
Now, lets assume that a request comes into the queue and thread T1 picks up
and starts processing it. T1 has released r1_mutex lock and is holding
r2_mutex lock and is executing the code in lines 9 and 10.
While T1 is busy executing code on lines 9 and 10, the queue gets 4 more
requests and threads T2, T3, T4 and T5 (in that order) picks each one of
them in the order in which they came into the queue and start processing
them. They come till LINE 8 and wait to lock r2_mutex which thread T1 has
currently locked.
Now, given this scenario, here is my question:
After T1 unlocks r2_mutex, which thread among T2, T3, T4 and T5 gets the
r2_mutex lock? Does pthread scheduler schedule (give the lock to) thread T2
which came to LINE8 first??
Sreevathsa,
I will not ask you why you want to enforce some sort of artificial
"scheduling policy" for your threads with regard to the problem you're
trying to solve. I'd generally recommend decoupling the comsumer
pattern from the communication pattern. While a FIFO guarantees items
to be processed in a particular order, the order of execution of
threads is beyond your control, unless you apply a scheduling policy
to each thread, which may require superuser privileges (see SCHED_FIFO
and SCHED_RR).
You may want to create a chain of threads (instead of a tree), each
one waiting for the other to complete (see pthread_join). Every
controller thread could then create a single worker thread to process
the data, thus the controller thread can relinquish the CPU
afterwards.
Anyhow, I recommend not to rely on the order of items arriving in the
FIFO. Instead, I'd introduce another layer of abstraction to map
items to particular threads.
\Steve
--
Steve Grägert <steve@xxxxxxxxxxxx>
Jabber xmpp://graegerts@xxxxxxxxxx
Internet http://eth0.graegert.com, http://blog.graegert.com
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
