| Sibin Thomas <sibinpthomas@gmail.com>: Aug 31 10:08AM -0700 On Wednesday, 31 August 2016 17:11:19 UTC+5:30, Casper H.S. Dik wrote: > and of that point the it can be locked by other threads. The blocked threads, or > at least one of them, will be awoken. The lock is not handed to that thread. > Casper Thanks. That clears my doubts. |
| Kaz Kylheku <221-501-9011@kylheku.com>: Aug 31 05:59PM > 3. Thread 1 unlocks the lock. > At this juncture can another thread (say, Thread 3) swoop in and make > a request for the lock and acquire it (as shown in the image below)? This may depend on the mutex attributes. Such a requirement is not defined for any of the standard mutex types (PTHREAD_MUTEX_NORMAL, PTHREAD_MUTEX_DEFAULT, etc). A strict mutex like this could be provided as some platform-specific type. A pthread implementation could even map the default type to such a mutex. (Since that will negatively affect throughput for the sake of fairness, unlikely). >> available, the scheduling policy shall determine which thread shall >> acquire the mutex. > This seems to say that Thread 3 can not swoop in and acquire the mutex, though I am not fully assured. Yes, on a single processor, the scheduling policy will effectively decide that, taking into consideration thread priorities. The unlock operation will wake up a waiting thread. So then in your scenario, you have three threads which are runnable. The original thread (which is presumably going off to do something else and not contending for the mutex), the woken thread, and the opportunistic one. Only one thread at a time can run on the processor. Between the two threads which want the mutex, the one that will get it will be the one which runs first, and that is up to the scheduler. On a multiprocessor, the opportunistic thread can, however, be actually executing on one processor as the mutex is unlocked on another processor, and can perhaps snatch the mutex via an atomic operation not even involving a trip to the kernel. The thread which was woken from waiting on the mutex tries the same atomic operation and finds that it fails. |
| Kaz Kylheku <221-501-9011@kylheku.com>: Aug 31 06:08PM > I was influenced by the discussion here - http://austingroupbugs.net/view.php?id=609 > I thought similar to pthread_signal() pthread_mutex_unlock() too does an "atomic unblock" of threads already in its 'Wait queue' pthread_cond_{signal,broadcast} do not do any atomic unblock, and can be invoked without the mutex being held. The atomicity is in the pthread_cond_{wait,timedwait} operations. From the application point of view, it appears that transition of from "mutex owner" to "waiting on condition" is atomic. There is no in-between window of time during which the signal or broadcast could take place such that a thread is neither mutex owner, nor waiting on the condition. The signal/broadcast itself though is basically just a best effort: whatever thread or threads, are actually waiting at the moment of the call are woken up, and that's it. |
| Sibin Thomas <sibinpthomas@gmail.com>: Sep 01 03:50AM -0700 On Wednesday, 31 August 2016 23:38:55 UTC+5:30, Kaz Kylheku wrote: > The signal/broadcast itself though is basically just a best effort: > whatever thread or threads, are actually waiting at the moment of the > call are woken up, and that's it. Thanks for your input Kaz, much appreciated. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.programming.threads+unsubscribe@googlegroups.com. |
No comments:
Post a Comment