Talk:Monitor (synchronization)

From Wikipedia, the free encyclopedia

Hi guys, I added the bit about Mesa vs. Hoare semantics, but was logged in anonymously. Just wanted to put a name to the edit. I'm not sure if it's really the most elegant way to display the information; does anyone have any suggestions? --Voorhies 22:22, 7 March 2007 (UTC)

Hi, I was just wondering, is there some way that this page can appear when one searches for "java monitor"? Currently the Javan Rhinocerous gets a higher relevancy then "concurrent programming languages" when using that search term, and this page doesn't appear at all. Thanks! Nekonobaka

A good overview article, but the paragraph "In most modern implementations,..." is a bit misleading to my mind. This "modern" monitor way is the sematics of Java Programming Language. For some reason (perhaps speed which is a bad argument in safety critical systems) they did not follow monitor semantics defined in 70's but made their own. This causes much confusion (in this very page the queue examples do not work correctly if they are to be implemented in java).

Perhaps this page should tell that there are three semantics in use for monitors: hoare (signal-and-wait), mesa (signal-and-continue) and Java (the "modern").

"C# does not have monitors as a feature of the language". We-ell. C# has a "lock" mechanism which is directly analagous to Java's synchronized mechanism; it happens that it's implemented using the Framework's Monitor class internally (see http://research.microsoft.com/~birrell/papers/ThreadsCSharp.pdf ), but any hypothetical "free-standing" C# implementation (i.e. one not tied to Rotor, .NET FX, Mono, DotGNU, etc.) would have to have an equivalent mechanism. As such it seems to me that C# probably does have built-in monitors, at least to the same extent as Java does. DrPizza 18:07, 9 October 2005 (UTC)

[edit] Condition variable

I think that 'Condition variables' can live without a monitor. If that is right, why Condition variable redirects here?

You're mistaken. Condition variables were developed specifically for monitors, and I've never heard of anyone recommending their use outside that context. Gazpacho 04:30, 14 April 2006 (UTC)

condition variables are used all over the place. even with java, for example, every object has a condition variable built in with the wait(), signal(), and signalAll() methods supported at the Object class. 68.83.85.175 00:25, 6 November 2006 (UTC)

Condition variables were introduced for use with monitors, but they are definitely useful in and of themselves. By way of reference, none of the pthread condition variable man pages mention the word "monitor". The key behavior of condition variables, allowing a single thread to signal multiple waiting threads, is not monitor-specific. I don't know if that means a condition variable is worthy of its own article, but they are perfectly okay to use outside monitors. ScotS (talk) 23:42, 12 December 2007 (UTC)

[edit] Room_synchronization

Someone queried the difference between this article and Room_synchronization, can someone who knows more than I take a quick look at that page? 212.44.19.62 13:27, 21 April 2006 (UTC)

[edit] Condition Variable example ?

I think the example is wrong: when doing wait(), the queueSize is increased, but never decreased. I think there should be a queueSize-- following the waiting.up(). -- Marc —The preceding unsigned comment was added by 193.49.124.107 (talk) 11:17, 15 May 2007 (UTC). Marc, you must be right, decreasing it that way is safe as it's protected, and else you would always have signal>0 once this is true once, therefore i correct the algorithm... Cédric —Preceding unsigned comment added by Gonnet (talk • contribs) 01:35, August 27, 2007 (UTC)

I have another question about the CV example code. Consider thread A running wait(), after releasing lock but before pending on waiting. Thread A is pre-empted by thread B which does signal(), which runs to completion, leaving waiting "up" and lock unlocked, meaning a possible lucky thread C could wait() and run straight through, bypassing the poor original thread A, even though C arrived at wait() after signal() ran and should therefore have had to wait until the next call to signal(). The fact that A didn't get signalled isn't the end of the world, since it will catch the signal intended for C the next time and A's wait() hadn't returned anyway, so A didn't really expect to catch the first signal() -- the possible problem is C getting to skip a wait(). I may be missing something, perhaps specific to the monitor use case of CV's or to the assumed semantics of waiting.up(), that makes this okay. Can you clarify what I'm missing? ScotS (talk) 23:55, 12 December 2007 (UTC)