when pthread_unlock(mutex) is called , do other threads waiting for mutex be waked up immediately? or be waked up at the next schedule?
On Tue, Mar 5, 2013 at 10:14 AM, ishare <june.tune.sea@gmail.com> wrote:
when pthread_unlock(mutex) is called , do other threads waiting for mutex be waked up immediately? or be waked up at the next schedule?
next schedule. I think the waiting threads (processes) will moved from the wait queue to the run queue from where they will be scheduled to run. HTH, -mandeep
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Tue, 05 Mar 2013 11:02:45 +0530, Mandeep Sandhu said:
next schedule. I think the waiting threads (processes) will moved from the wait queue to the run queue from where they will be scheduled to run.
For bonus points, read source code and/or comments and figure out what Linux does to prevent the 'thundering herd' problem (consider 100 threads all waiting on the same mutex - if you blindly wake all 100 up, you'll schedule them all, the first will find the mutex available and then re-take it, and then the next 99 will get run only to find it contended and go back to sleep. So figure out what Linux does in that case. :)
On Tue, Mar 5, 2013 at 11:32 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Tue, 05 Mar 2013 11:02:45 +0530, Mandeep Sandhu said:
next schedule. I think the waiting threads (processes) will moved from the wait queue to the run queue from where they will be scheduled to run.
For bonus points, read source code and/or comments and figure out what Linux does to prevent the 'thundering herd' problem (consider 100 threads all waiting on the same mutex - if you blindly wake all 100 up, you'll schedule them all, the first will find the mutex available and then re-take it, and then the next 99 will get run only to find it contended and go back to sleep. So figure out what Linux does in that case. :)
Googling around, I found the 'thundering herd' being mentioned in relation to threads waiting on sockets using the accept() sys call. Are wait's on mutex's also plagued by the same issue? I guess it is, though what sys call would be used in this case? Thanks, -mandeep
On Tue, Mar 05, 2013 at 01:39:54PM +0530, Mandeep Sandhu wrote:
On Tue, Mar 5, 2013 at 11:32 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Tue, 05 Mar 2013 11:02:45 +0530, Mandeep Sandhu said:
next schedule. I think the waiting threads (processes) will moved from the wait queue to the run queue from where they will be scheduled to run.
For bonus points, read source code and/or comments and figure out what Linux does to prevent the 'thundering herd' problem (consider 100 threads all waiting on the same mutex - if you blindly wake all 100 up, you'll schedule them all, the first will find the mutex available and then re-take it, and then the next 99 will get run only to find it contended and go back to sleep. So figure out what Linux does in that case. :)
Googling around, I found the 'thundering herd' being mentioned in relation to threads waiting on sockets using the accept() sys call. Are wait's on mutex's also plagued by the same issue? I guess it is, though what sys call would be used in this case?
the threads waiting on sockets will be waked up by net event. similarly,the waiters on mutex's can be wake up by signal.I guess it is pthread_cont_signal
Thanks, -mandeep
I guess we should not mix mutex and condition variable. Both have their own respective semantics. *mutex* is used to serialize access to a shared resource among competing threads. *condition variable* is used to notify a* state change* of a resource to the interested thread. In case of condition variable there is provision to explicitly notify a single thread(pthread_cond_signal) or all the threads waiting on a condition (or a state change) (pthread_cond_broadcast) Question was on pthread_mutex_unlock() that whether this function invocation will trigger the movement of all the threads in the wait queue to the ready queue. If all the threads are of equal priority, then the first thread waiting for the lock will be put to READY queue. If there are variable priority threads waiting for the lock, then the thread with highest priority would be woken up Regards, Prabhunath G Linux Trainer Bangalore On Tue, Mar 5, 2013 at 3:35 PM, ishare <june.tune.sea@gmail.com> wrote:
On Tue, Mar 05, 2013 at 01:39:54PM +0530, Mandeep Sandhu wrote:
On Tue, Mar 5, 2013 at 11:32 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Tue, 05 Mar 2013 11:02:45 +0530, Mandeep Sandhu said:
next schedule. I think the waiting threads (processes) will moved from the wait queue to the run queue from where they will be scheduled to run.
For bonus points, read source code and/or comments and figure out what Linux does to prevent the 'thundering herd' problem (consider 100 threads all waiting on the same mutex - if you blindly wake all 100 up, you'll schedule them all, the first will find the mutex available and then re-take it, and then the next 99 will get run only to find it contended and go back to sleep. So figure out what Linux does in that case. :)
Googling around, I found the 'thundering herd' being mentioned in relation to threads waiting on sockets using the accept() sys call. Are wait's on mutex's also plagued by the same issue? I guess it is, though what sys call would be used in this case?
the threads waiting on sockets will be waked up by net event. similarly,the waiters on mutex's can be wake up by signal.I guess it is pthread_cont_signal
Thanks, -mandeep
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Tue, Mar 12, 2013 at 06:18:02PM +0530, Prabhu nath wrote:
I guess we should not mix mutex and condition variable. Both have their own respective semantics. *mutex* is used to serialize access to a shared resource among competing threads. *condition variable* is used to notify a* state change* of a resource to the interested thread.
In case of condition variable there is provision to explicitly notify a single thread(pthread_cond_signal) or all the threads waiting on a condition (or a state change) (pthread_cond_broadcast)
Question was on pthread_mutex_unlock() that whether this function invocation will trigger the movement of all the threads in the wait queue to the ready queue.
After pthread_mutex_unlock() is called , the mutex is release , then ,which stuff will reshcedule the threads in the waitqueue ? If do pthread_cond_signal() after each pthread_mutex_unlock() ,does it raise up the performence ? thanks!
If all the threads are of equal priority, then the first thread waiting for the lock will be put to READY queue. If there are variable priority threads waiting for the lock, then the thread with highest priority would be woken up
On Wed, Mar 13, 2013 at 9:40 AM, ishare <june.tune.sea@gmail.com> wrote:
On Tue, Mar 12, 2013 at 06:18:02PM +0530, Prabhu nath wrote:
I guess we should not mix mutex and condition variable. Both have their own respective semantics. *mutex* is used to serialize access to a shared resource among competing threads. *condition variable* is used to notify a* state change* of a resource to the interested thread.
In case of condition variable there is provision to explicitly notify a single thread(pthread_cond_signal) or all the threads waiting on a condition (or a state change) (pthread_cond_broadcast)
Question was on pthread_mutex_unlock() that whether this function invocation will trigger the movement of all the threads in the wait queue to the ready queue.
After pthread_mutex_unlock() is called , the mutex is release , then ,which stuff will reshcedule the threads in the waitqueue ?
If do pthread_cond_signal() after each pthread_mutex_unlock() ,does it raise up the performence ?
thanks!
I think you are missing something in your understanding. Please refer "Programming with POSIX threads" - David R. Butenhof
If all the threads are of equal priority, then the first thread waiting for the lock will be put to READY queue. If there are variable priority threads waiting for the lock, then the thread with highest priority would be woken up
-- Regards, Prabhunath G Linux Trainer Bangalore
participants (4)
-
ishare -
Mandeep Sandhu -
Prabhu nath -
Valdis.Kletnieks＠vt.edu