- A Java- / .NET-like monitor - 9 Updates
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 12 05:40AM +0100 Am 11.11.2023 um 20:42 schrieb Chris M. Thomasson: > Is that yet another bug correction? Remember my advise, get it working > then try to make it faster. The code immediately crashed because of an exception; easiest debugging. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 12 05:43AM +0100 Am 11.11.2023 um 23:45 schrieb Pavel: >>> Yawn. >> Re-acquiring the mutex part of a monitor after notify() > is exactly what Java does -- and it does it for reason. No, Java and .net keep holding the mutex while doing a notify(). That's called a Mesa monitor. |
| Kaz Kylheku <864-117-4973@kylheku.com>: Nov 12 05:02AM > No, Java and .net keep holding the mutex while doing a notify(). > That's called a Mesa monitor. I don't suspect that is part of Mesa semantics. (It's definitely part of Hoare semantics.) Do you have a reference? Since under Mesa semantics, threads re-acquire the mutex with fewer guarantees and must re-test the desired condition, Mesa semantics supports the more efficient protocol of signaling outside of the monitor. If you're using POSIX mutexes and conditions, you should call pthread_cond_signal and pthread_cond_broadcast outside of the mutex, whenever possible. (In a nutshell, if you're going to be telling some thread(s) to go ahead and grab a mutex, get the hell out of their way first). -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 12 11:00AM +0100 Am 12.11.2023 um 06:02 schrieb Kaz Kylheku: > I don't suspect that is part of Mesa semantics. (It's definitely part of > Hoare semantics.) Do you have a reference? Wikipedia (https://en.wikipedia.org/wiki/Monitor_(synchronization): "With nonblocking condition variables (also called "Mesa style" condition variables or "signal and continue" condition variables), signaling does not cause the signaling thread to lose occupancy of the monitor. Instead the signaled threads are moved to the e queue." > guarantees and must re-test the desired condition, Mesa semantics > supports the more efficient protocol of signaling outside of the > monitor. This is a theoretical advantage. In fact, a combination of mutex and condition variable, like a monitor implicitly is, is intended for procuder-consumer patterns. And at this point it never happens that you want to signal something but don't modify a common state. > If you're using POSIX mutexes and conditions, you should call > pthread_cond_signal and pthread_cond_broadcast outside of the > mutex, whenever possible. That actually never happens because you have to lock the mutex anyway. |
| Kaz Kylheku <864-117-4973@kylheku.com>: Nov 12 05:18PM > signaling does not cause the signaling thread to lose occupancy > of the monitor. Instead the signaled threads are moved to the e > queue." That doesn't say that signaling *requires* the monitor to be held, though! >> supports the more efficient protocol of signaling outside of the >> monitor. > This is a theoretical advantage. No it isn't. The signal operation can trap into a kernel, which can require hundreds of cycles. The mutex/monitor should ideally be only held only as long as necessary to protect the shared variables, and not be extended over unrelated, lengthy operations. That encourages unnecessary contention. >> mutex, whenever possible. > That actually never happens because you have to lock the mutex > anyway. Pardon me, what is it that you believe doesn't actually happen? People coding this: // ... pthread_mutex_unlock(&obj->mtx); pthread_cond_signal(&obj->foo_cond); rather than this: // ... pthread_cond_signal(&obj->foo_cond); pthread_mutex_unlock(&obj->mtx); ? -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted. |
| scott@slp53.sl.home (Scott Lurndal): Nov 12 05:53PM >> mutex, whenever possible. >That actually never happens because you have to lock the mutex >anyway. No, you don't. If you updated the predicate that the condition variable is monitoring while holding the mutex, you should release the mutex before signaling or broadcasting the condition variable to avoid unnecessary context switches. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 12 12:46PM -0800 On 11/11/2023 8:40 PM, Bonita Montero wrote: >> then try to make it faster. > The code immediately crashed because of an exception; > easiest debugging. Yet, you missed it? Actually, I am not quite sure how to parse your response. I have not had the free time to port your code over to a Relacy test unit, yet... :^) |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 12 12:48PM -0800 On 11/12/2023 2:00 AM, Bonita Montero wrote: > signaling does not cause the signaling thread to lose occupancy > of the monitor. Instead the signaled threads are moved to the e > queue." Humm... A wait morph? ;^) |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 12 12:51PM -0800 On 11/12/2023 9:53 AM, Scott Lurndal wrote: > variable is monitoring while holding the mutex, you should release > the mutex before signaling or broadcasting the condition variable > to avoid unnecessary context switches. Yup. Actually, there was an old discussion about this around 20 ish years ago back on comp.programming.threads. David Butenhof was involved. |
| 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.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment