About synchronization methods
Ankur
I'm new to the this group, so kindly pardon me if my questions are not
appropriate in any way.
Ok some basics..
What are the difference between the various thread synchronization
methods such as mutexes, semaphores, conditions variables, monitors,
so on (if there are any more).
Of what I understood from the information available (at wikipedia and
stuff):-
- Mutex is just a binary semaphore that is used to synchronize access
to a single resource by atmost 2 threads whereas a semaphore is used
to synchronize access to a shared resource by more than 2 threads. And
both of these mechanisms are programmer controlled.
- Condition variables provide yet another way for threads to
synchronize. While mutexes implement synchronization by controlling
thread access to data, condition variables allow threads to
synchronize based upon the actual value of data. This is also
programmer controlled. I know of "pthread_cond_t" construct in the
pthread library but are there any equivalent construct for conditions
variable in the Win32 or C runtime library (Libcmt & msvcrt) or MFC
- With monitor-based concurrency, the compiler or interpreter
transparently inserts locking and unlocking code to appropriately
designated procedures, instead of the programmer having to access
concurrency primitives explicitly. This is a more structured form of
synchronization.
I would like to know more about the above (specially about monitors).
Could someone please provide some kind of detailed explanation (or
some good resource on the Internet).
'Would appreciate your inputs.
Thanks!
Dave Butenhof
> Hi Folks!
>
> I'm new to the this group, so kindly pardon me if my questions are not
> appropriate in any way.
>
> Ok some basics..
>
> What are the difference between the various thread synchronization
> methods such as mutexes, semaphores, conditions variables, monitors,
> so on (if there are any more).
>
> Of what I understood from the information available (at wikipedia and
> stuff):-
>
> - Mutex is just a binary semaphore that is used to synchronize access
> to a single resource by atmost 2 threads whereas a semaphore is used
> to synchronize access to a shared resource by more than 2 threads. And
> both of these mechanisms are programmer controlled.
I can almost imagine that there's a small grain of validity in that;
but, no, that's not true. Or at least is so badly stated as to be almost
entirely misleading.
Yes, a mutex is essentially a binary semaphore, with a critical semantic
distinction that it has the concept of "ownership" while a semaphore
does not. Ownership is mostly of value for debugging and analysis tools,
because misuse can be diagnosed; e.g., because the mutex was unlocked by
a thread that doesn't currently own it, or because the current owner
attempts to relock it.
To some extent, you could consider a mutex or semaphore a "point to
point" transaction; between unlock and lock, or between post and wait;
but it can be any two threads out of the set. Both semaphores and
mutexes may be private to a process (usable only by the threads in that
process), which may sometimes be cheaper to implement; or they may be
shared among threads in different processes. (Either through commonly
mapped user-mode shared memory as in POSIX mutexes and semaphores, BSD
binary semaphores; or as pure kernel objects as System V semaphores.)
The big difference in use between binary semaphores (or mutexes) and
counting semaphores is that the latter includes shared data that can be
communicated (with some restrictions), rather than only synchronization.
For example, in a work queue model, you might have a counter for the
number of items available. You can lock a mutex (or binary semaphore),
decrease or increase the counter, unlock, and take some action. OR, with
a counting semaphore, you use something like sem_post() to denote
addition of a new item; and depending on interface, if you add three
items you may be able to do this with a single call. The system is
managing the count as part of the synchronization protocol. This can
sometimes be useful, or it can be maddeningly frustrating. (Limitations
include the fact that while you can usually READ the current value of
the counter, there's no way to perform this feat atomically with some
action upon the semaphore; which can make for complicated logic. That
is, you cannot assume because you just read a value of <n>, that the
next wait/post operation will behave as if the value is <n>; it may have
changed.)
But it's this "multiple value" property, the ability to record in the
semaphore that there are THREE entities available, that might lead
someone to talk about "multiple threads" -- a producer can enqueue 3
buffers, for example, and post an increment of 3 which, at least in
theory, may "simultaneously" release 3 waiting threads. This type of
operation, involving predicate management beyond simple synchronization,
isn't part of the mutex model -- instead you'd use condition variables
to manage the predicate while the mutex controls only synchronization.
> - Condition variables provide yet another way for threads to
> synchronize. While mutexes implement synchronization by controlling
> thread access to data, condition variables allow threads to
> synchronize based upon the actual value of data. This is also
> programmer controlled. I know of "pthread_cond_t" construct in the
> pthread library but are there any equivalent construct for conditions
> variable in the Win32 or C runtime library (Libcmt & msvcrt) or MFC
Win32 uses "events", which encapsulates even more implicit state than
counting semaphores (set/reset), and can therefore be really convenient
for certain specific synchronization models, and extraordinarily tedious
and error prone for others. (It's too high level a model to be the only
predicate control mechanism. I've heard that Win32 has added something
like a condition variable.)
In the POSIX model, as I said before, you use the mutex to synchronize
access to your shared data predicates, and condition variables to help
efficiently manage threads' responses to predicate changes. For example,
a mutex serializes access to "a queue". Your own predicate data manages
the links to data, and perhaps a count of how many items are on the
queue. You might have one condition variable to manage thread responses
to the predicate condition "queue empty", and another for "queue not
empty". Threads that change the predicate will SIGNAL (waking a single
waiter) or BROADCAST (waking all waiters) when they change the predicate
state. For example, if you add the first item to an empty queue, you'd
signal the "not empty" condition variable. Threads that need a specific
state to operate (you can't remove an item until there is one) will wait
on the appropriate condition. (while queue empty, wait for not empty).
Condition variable waits are always in predicate test LOOPS; because
it's possible that some other thread will have changed the predicate
before your waiter wakes up, or perhaps even before the signal occurred.
(A common construct is "lock, change data, unlock, signal condition if
something changed". This can be efficient, because it reduces the amount
of time a mutex is held and therefore can increase concurrency; the cost
is a certain, um, "looseness" in predicate consistency, which usually is
a good trade.)
> - With monitor-based concurrency, the compiler or interpreter
> transparently inserts locking and unlocking code to appropriately
> designated procedures, instead of the programmer having to access
> concurrency primitives explicitly. This is a more structured form of
> synchronization.
"Monitor" is a word widely used for lots of different things; be careful
about overgeneralizing or assuming too much. In most cases, a monitor is
an explicit object you use to manage shared data predicates. But it has
many widely varying forms. Basically, think of a monitor as "mutex +
condition variable + shared predicates", and you'll have the basic idea.
It implies that the monitor knows something about the data state; while
a mutex and condition variable don't.
> I would like to know more about the above (specially about monitors).
> Could someone please provide some kind of detailed explanation (or
> some good resource on the Internet).
To get much more detail, you'd need to have a particular "monitor" model
in mind, so you'll need to be more specific.
Szabolcs Ferenczi
> [...]
> - Mutex is just a binary semaphore that is used to synchronize access
> to a single resource by atmost 2 threads whereas a semaphore is used
> to synchronize access to a shared resource by more than 2 threads. And
> both of these mechanisms are programmer controlled.
It is correct that the mutex is a binary semaphore. However, it
synchronises access to a resource among N threads. The semaphore is a
general synchronisation tool that can be used to control resource
access as well as to implement synchronisation on some event among N
processes.
The mutex is a special means in that you must use mutexes if you use
condition variables.
> - Condition variables provide yet another way for threads to
> synchronize.
Condition variables are just a performance optimisation means. You
cannot use the condition variable on its own but you need a mutex and
you must have a predicate what you are interested in in your process.
The mutex implements the Critical Region while the condition variable
makes the waiting loop for the predicate optimal in terms of processor
cycles.
> While mutexes implement synchronization by controlling
> thread access to data, condition variables allow threads to
> synchronize based upon the actual value of data. This is also
> programmer controlled. I know of "pthread_cond_t" construct in the
> pthread library but are there any equivalent construct for conditions
> variable in the Win32 or C runtime library (Libcmt & msvcrt) or MFC
You should consider that in concurrent programming we speak of short
term synchronisation and long term one. One low level programming tool
for short term synchronisation is the mutex. For long term you can
synchronise your processes with condition variables or with
semaphores.
Please note that mutexes and condition variables are low level
synchtonisation tools at the library level. If there were high level
languages available, you would not need any mutexes nor condition
variables at the language level.
> - With monitor-based concurrency, the compiler or interpreter
> transparently inserts locking and unlocking code to appropriately
> designated procedures, instead of the programmer having to access
> concurrency primitives explicitly. This is a more structured form of
> synchronization.
Correct but the main aim of the monitor is that the compiler can check
for you that your shared data is accessed in Critical Regions only.
Monitors provide modularity, i.e. it merges shared data and
Conditional Critical Regions.
> I would like to know more about the above (specially about monitors).
> Could someone please provide some kind of detailed explanation (or
> some good resource on the Internet).
I think the best is the first hand source:
The invention of concurrent programming by Per Brinch Hansen:
http://brinch-hansen.net/papers/2002b.pdf
If you read this carefully you will see how monitors and condition
variables were invented and why. You will learn why we can say that
condition variables are performance optimisation means.
Keep your focus on Conditional Critical Regions.
Best Regards,
Szabolcs
Giancarlo Niccolai
>
> Win32 uses "events", which encapsulates even more implicit state than
> counting semaphores (set/reset), and can therefore be really convenient
> for certain specific synchronization models, and extraordinarily tedious
> and error prone for others. (It's too high level a model to be the only
> predicate control mechanism. I've heard that Win32 has added something
> like a condition variable.)
>
From 2000 server, I have witnessed the first try to emulate condition
variables:
DWORD WINAPI SignalObjectAndWait(
__in HANDLE hObjectToSignal,
__in HANDLE hObjectToWaitOn,
__in DWORD dwMilliseconds,
__in BOOL bAlertable
);
It would seem a sort of pthread_cond_wait, but it's wicked as it
requires a Windows Mutex to work (which is actually an interprocess
semaphore, much more complex and times slower than what we call
"mutex"). Also, the monster still needs and works with windows events,
and can become an APC (overlapped) callback point... Seems very like a
swiss army cutter: too useful to serve any need.
With Vista, they seem to have learned the lesson:
http://msdn.microsoft.com/en-us/library/ms682052(VS.85).aspx
InitializeConditionVariable Initializes a condition variable.
SleepConditionVariableCS Sleeps on the specified condition variable and
releases the specified critical section as an atomic operation.
SleepConditionVariableSRW Sleeps on the specified condition variable
and releases the specified SRW lock as an atomic operation.
WakeAllConditionVariable Wakes all threads waiting on the
specified condition variable.
WakeConditionVariable Wakes a single thread waiting on the specified
condition variable.
... May that be that they just recognized the superiority of the POSIX
model and messed up the names to sneak it as if it was a finding of
theirs? :-) HHJK.
Giancarlo.
Szabolcs Ferenczi
> Basically, think of a monitor as "mutex +
> condition variable + shared predicates", and you'll have the basic idea.
Hmmm.... That is not exactly correct. The basic idea of the monitor is
beyond that low level thinking with library calls.
First: The mutex has nothing to do with the basic idea of the monitor,
except for that you can build a monitor-like construction by hand with
mutexes and condition variables. Equally well you can build a monitor-
like construction by hand with semaphores and you would not say that
`think of a monitor as "semaphores + shared predicates", and you'll
have the basic idea', would you. The mutex is nothing else but some
low level library-based means to implement the language level Critical
Region or the language level Conditional Critical Region if you add
the condition variable as well. Even so, one important aspect will be
missing compared to the language level monitor solution and that is
the association of the shared data with the (Conditional) Critical
Region. That association is added by the monitor concept and that is
still missing from your formula above, i.e., it is missing from any
attempt to hand build the monitor construction from low level library
elements.
Second: The claim that the condition variable has something to do with
the basic idea of the monitor is more close to the truth at least.
Although, you must be aware that if the monitor is part of a
concurrent programming language, no mutex is needed and no condition
variable is necessary since the monitor is basically a shared class
that implements Conditional Critical Regions, which do not have any
condition variable. It is interesting to note that originally the
monitor was called a shared class and did not have any condition
variable either.
http://brinch-hansen.net/papers/1973b.pdf
However, the condition variable might be provided in the
implementation to optimise the waiting (loop) of the process, which is
waiting for the correct state of the shared data to proceed. However,
in the original monitor concept (from Hoare) even a waiting loop was
not necessary since it is not part of the concept. Part of the concept
was, however, the scheduling policy around the monitor, namely, that
re-scheduled processes (from condition variables) have priority over
the ones trying to enter the monitor.
http://pages.cs.wisc.edu/~cs736-1/cs736.html/Papers/hoare-monitors.pdf
More exactly, the concept of the underlying Conditional Critical
Region only says that an operation on the shared data must be
_delayed_ until the state of the shared data makes it possible for the
process to carry out the operation. That is why you can express it at
the language level that your operation awaits a certain predicate as a
condition (guard) to proceed. It is also interesting to note that as
the first attempt in the optimisation effort, queuing variables were
provided for the long term scheduling of the processes rather than
condition variables.
http://brinch-hansen.net/papers/2002b.pdf
However, those condition variables introduced by Hoare had different
semantics from the low level Mesa-like ones taken over by Pthread. In
fact the delay mechanism of the monitor construction (whether queuing
variables or condition variables) was an engineering compromise
between the elegance and expressive power of the Conditional Critical
Region and the efficiency of the implementation.
Third: In fact, even the third element of that formula is problematic,
since not the predicates are shared but it is the data space which is
shared. The data space is encapsulated by the monitor. The added value
was that at the language level you could encapsulate the shared data
and the operations on it and the compiler could support you in that it
could check that the shared data was accessed in a safe way.---
However, with the low-level library-based mutexes and condition
variables all this safety is gone.
Only that much is problematic from the above low level formula.
I hope I was of help.
Best Regards,
Szabolcs
Dave Butenhof
> On Jun 1, 7:21 pm, Dave Butenhof <david.buten...@hp.com> wrote:
>
>> Basically, think of a monitor as "mutex +
>> condition variable + shared predicates", and you'll have the basic idea.
>
> Hmmm.... That is not exactly correct. The basic idea of the monitor is
> beyond that low level thinking with library calls.
A monitor (of any of a wide range of actual meanings for that term in
wide and varied use) may be implemented using a wide range of tools. I
am however speaking of the behavioral semantics of the most common
meanings. A monitor is, precisely, the synchronization and control that
is embodied by the POSIX mutex and semaphore concepts, bundled with
actual predicate data. That's why I said "think of a monitor as". Do you
not understand the concept of "analogy"? That might explain a lot...
> First: The mutex has nothing to do with the basic idea of the monitor,
> except for that you can build a monitor-like construction by hand with
> mutexes and condition variables. Equally well you can build a monitor-
> like construction by hand with semaphores and you would not say that
> `think of a monitor as "semaphores + shared predicates", and you'll
> have the basic idea', would you. The mutex is nothing else but some
> low level library-based means to implement the language level Critical
> Region or the language level Conditional Critical Region if you add
> the condition variable as well. Even so, one important aspect will be
> missing compared to the language level monitor solution and that is
> the association of the shared data with the (Conditional) Critical
> Region. That association is added by the monitor concept and that is
> still missing from your formula above, i.e., it is missing from any
> attempt to hand build the monitor construction from low level library
> elements.
As you say, and despite your misleading first sentence, a monitor
embodies the synchronization and communication mechanism that POSIX
packages as mutex and condition variable, and combines it with the data
predicate being managed.
You do that a lot, in fact, when you're not talking complete nonsense.
You are arguing about trivial details while completely overlooking and
actively obscuring any actual meaning.
I know you have your own agenda, trying to sell everyone on language
models that include transparent parallelization, and that's great. Those
languages and models are not, at least not yet (if ever) available to
every developer nor appropriate for every need. By aggressively selling
yourself as an intolerant and pigheaded zealot, you are doing more harm
than good for your cause.
> Second: The claim that the condition variable has something to do with
> the basic idea of the monitor is more close to the truth at least.
> Although, you must be aware that if the monitor is part of a
> concurrent programming language, no mutex is needed and no condition
> variable is necessary since the monitor is basically a shared class
> that implements Conditional Critical Regions, which do not have any
> condition variable. It is interesting to note that originally the
> monitor was called a shared class and did not have any condition
> variable either.
This could be taken as a statement that you have no idea at all how
monitors, mutexes, or condition variables are constructed. Or it could
be taken as silly smokescreen to pretend to sound intelligent and deep.
But if you can't comprehend the essential parallels and similarities in
construction and purpose, then you're far worse off than you make
yourself appear regularly in this forum. So I guess I'll have to go with
"smokescreen". See "zealot", and "harming your cause". And, yeah, I can
imagine your return arguments; please, don't bother. You're sufficiently
repetitive and pointless as it is.
> I hope I was of help.
Probably not. You've succeeded in confusing and complicating a simple
answer to a reasonable question, though; and perhaps that was your
intent. You did, at least, add some document pointers which I would
recommend to anyone who wants to figure out what's going on behind
Szabolcs' smoke screen. It's not as complicated as he makes it sound.
Szabolcs Ferenczi
> [...]
> A monitor is, precisely, the synchronization and control that
> is embodied by the POSIX mutex and semaphore concepts, bundled with
> actual predicate data.
The monitor concept is nothing to do with POSIX. The monitor concept
is worked out at the higher programming language level long before
POSIX would introduce its low level library primitives. Do not think
that concurrent programming starts with POSIX.
If you do not know about the monitor concept, I have given you some
first hand references. I highly recommend you to read them and then
you will perhaps know what we are speaking about.
http://brinch-hansen.net/papers/1973b.pdf
http://pages.cs.wisc.edu/~cs736-1/cs736.html/Papers/hoare-monitors.pdf
http://brinch-hansen.net/papers/2002b.pdf
> By aggressively selling
> yourself as an intolerant and pigheaded zealot, you are doing more harm
> than good for your cause.
Please calm down and try to learn instead of permanently trying to
insult me and being personal. Try to be professional instead.
Thank you.
Best Regards,
Szabolcs
Dave Butenhof
> On Jun 2, 8:35 pm, Dave Butenhof <david.buten...@hp.com> wrote:
>> [...]
>> A monitor is, precisely, the synchronization and control that
>> is embodied by the POSIX mutex and semaphore concepts, bundled with
>> actual predicate data.
>
> The monitor concept is nothing to do with POSIX. The monitor concept
> is worked out at the higher programming language level long before
> POSIX would introduce its low level library primitives. Do not think
> that concurrent programming starts with POSIX.
Sheesh. You ignore and refute any attempt at civility. You haven't paid
attention to a single thing I said. You either don't understand or can't
see through your narrow minded bigotry to comprehend.
Whatever you would like the world to be, most people program threaded
applications using a simple library API and a standard programming
language like C or C++. Most programmers have at least a basic
understanding, or at least can easily learn, the simple concepts of
synchronization and communication. Therefore, they make excellent
building blocks for explaining the concept and use of higher level concepts.
And oddly, although you continually point out uselessly and abrasively
that POSIX did not invent the mutex and condition variable, EVERY single
time anyone uses one term or the other in a generic sense, as I did, you
rail against the poster for assuming POSIX is "all there is". I suppose
this is symptomatic of your intent to seem like the only reasonable
person in the world, unfairly criticized by everyone else.
POSIX happens to have a mutex and condition variable. After Win32, POSIX
is currently the most widely known and used threaded programming model.
As the composition of this newsgroup is overwhelmingly Linux and UNIX,
references to POSIX are generally far more valuable for illustrative
purposes and any other specifics. To take offense at a bare mention of
the term "POSIX", incidentally and well after introduction of the names
and concepts, in my note is inexcusably unprofessional of you.
Completely consistent with your general comportment in this forum, of
course; but is that really how you wish to be known?
Ankur
Guys, please calm down (This is not serving the purpose of the forum.)
At the same time, I highly appreciate you inputs and expertise on the
subject.
And thanks for providing the useful links.
I think, I need to do some through analysis of all the information
that you guys have provided, which will take some time.
Thanks again.
Cheers!
Chris Thomasson
news:f8e0a59a-da76-47a7...@2g2000hsn.googlegroups.com...
> Wow! I'm getting more than I bargained for.. :-)
> Guys, please calm down (This is not serving the purpose of the forum.)
There is a history with Szabolcs on several newsgroups which suggests that
he is a troll. AFAICT, his main mantra is something like:
`Please listen to me and try to learn something you ignorant fool!'
For instance, he made an assertion that condition variables cannot be used
to wait on events several times. When we tried to correct that false line of
thinking, he resorted to saying something like:
"Let me teach you because your obviously uneducated."
Oh well. ;^(
> At the same time, I highly appreciate you inputs and expertise on the
> subject.
> And thanks for providing the useful links.
> I think, I need to do some through analysis of all the information
> that you guys have provided, which will take some time.
> Thanks again.
> Cheers!
BTW, if you want to learn more about how to create correct programs which
adhere to the POSIX Thread Standard, read the following book:
http://www.amazon.com/exec/obidos/ASIN/0201633922
I highly recommend it.
Chris Thomasson
news:194f4e46-48c6-41b7...@2g2000hsn.googlegroups.com...
On Jun 1, 5:15 pm, Ankur <ankuraror...@gmail.com> wrote:
> > [...]
> > - Mutex is just a binary semaphore that is used to synchronize access
> > to a single resource by atmost 2 threads whereas a semaphore is used
> > to synchronize access to a shared resource by more than 2 threads. And
> > both of these mechanisms are programmer controlled.
> It is correct that the mutex is a binary semaphore. However, it
> synchronises access to a resource among N threads.
:^/
A binary semaphore has NO concept of ownership. However, a mutex does. See,
I think your being "misleading" here; you know better! If a newbie reads
this, she/he might think that since one can decrement the bin-sema in thread
A and increment it in thread B, then one could most certainly lock a mutex
in thread A and unlock it in thread B because Szabolcs said that a mutex is
nothing but a bin-sema.
The mutex introduces the concept of ownership which _fundamentally_
separates its behavior from that of a bin-sema...
[...]
Szabolcs Ferenczi
> And thanks for providing the useful links.
You are wellcome. Those are first hand resources from eminent
scholars. If you read them carefully, you will benefit from them. You
will not only know what synchronisation tool is available but you will
also know what to use them for and why.
Best Regards,
Szabolcs
Surinder Singh
mutex (mutual exclusion) is like holding authority exclusively to do
things like manipulating shared resource(s). if authority (i.e. lock)
is respected while coding, data corruption and deadlocks can be avoided.
simplest example is changing global variables in MT programs.
convar is thread waiting for a condition to occur which will be
signalled by some other thread when it happens. waiting thread sleeps
saving cpu cycles and wakes up only when required. if spurious wakeup
it checks for predicate and decides whether to proceed or sleep again.
mutex and condvar need to be used in intended manner to do so :)
for stable interfaces and documentation, try Solaris OS (its there for
x86 also) or Linux.
monitors : try mt programming with Java.
search "java multithreading synchronized" on net.
- Surinder
** Posted from http://www.teranews.com **
Ian Collins
>
> Please calm down and try to learn instead of permanently trying to
> insult me and being personal. Try to be professional instead.
>
--
Ian Collins.
Szabolcs Ferenczi
> monitors : try mt programming with Java.
> search "java multithreading synchronized" on net.
I would not recommend that, if someone is really interested in the
monitor concept. The Java guys themselves admit that what Java has is
not the true monitor but some low level means to implement a monitor-
like construction from, just like in the case of POSIX. Although you
can use Java with strong discipline but first you must learn about the
monitor concept.
The "monitor" in Java is considered harmful. Anyone interested in the
details can read the comments from the inventor of the monitor concept
himself about the insecure "monitors" in Java:
Java's insecure parallelism
http://brinch-hansen.net/papers/1999b.pdf
He concludes: "As it is, Java ignores the last twenty-five years of
research in parallel languages.", p.8
Best Regards,
Szabolcs
Chris Thomasson
What is the one true language, oh master? Humm... Let me guess; you have not
implemented it yet right?
;^)
Once you name the language, please name the one true language that is worthy
enough to implement the runtimes/virtual-machine for its holiness. I foresee
that your answer is going to be something like:
`Everybody with a stable working brain knows that the holy language is X
implemented with Y.'
How far off am I?
Dave Butenhof
Actually, Chris, and it pains me enormously to say this, on the subject
of Java "monitors" I agree 100% with Szabolcs, and very nearly wrote
essentially the same response myself when I saw the parent post's
reference to Java. (I overlooked it both because I saw the reference as
incidental to the post and also because I've discussed my "issues" with
Java synchronization often enough before... but I can't let this one go by.)
Szabolcs very definitely has an "agenda" with respect to language
support for threading, and can pursue it extremely and abrasively. And
I've already put in more than enough digs about the past history of a
certain well known citizen of this forum that I won't do it again, but
you know what I mean, and let's accept that as at least suggesting a
possibility that Szabolcs, too, might eventually become a member of
polite society.
In the case of Java, he's simply right. I think he was even pretty kind
about it. The use of the word monitor was ignorant and misleading. In
fact, as I've pointed out before in detail, the whole "language
supported" synchronization model of Java is nothing more than very
shallow semantic sugar over the standard library mutex and condition
variable synchronization model. As the language has no concept
whatsoever of data predicates or their meaning to the application, any
pretense of ability to manage anything like a "monitor" is pure fallacy;
and potentially dangerous fallacy for programmers who don't understand
the limitations. (Which, unfortunately, are NOT documented.)
It's possible for an APPLICATION to build something much like a monitor
(conforming roughly to the theoretical requirements) out of Java
synchronization and wait, along with Java object shared data -- just as
it is with POSIX, UI, or Win32 synchronization objects, communication
mechanisms, and shared data. But that doesn't mean Java supports
"monitors" any more than basic POSIX or Win32. The critical distinction
is that while the application may understand its shared data predicates
and synchronization requirements, the LANGUAGE (and/or library) does not
and cannot. (And the language can do a much better job of analyzing and
enforcing the rules; and only needs to be written and debugged once.)
The worst part of the Java synchronization model, and something
applications can attempt (hope) to avoid but not really even work
around, is the "spin out" wait construct, which automatically releases
the local lock -- even when it's been recursively locked by multiple
scopes. While defenders often support this on the grounds that "nobody
would ever be stupid enough to call wait [or anything that might call
wait] with a broken predicate", that's incredibly naive. And, more
importantly, a language that implements anything remotely deserving of
the term "monitor" would have to at least be able to detect and diagnose
such a programming error. (Actually, with a true monitor, this error is
simply impossible... which is the whole point.) It's quite easy to make
an error like that, and the effects are disastrous and difficult to debug.
So, yeah; the Java synchronization model is badly designed and
inherently broken. And, of more relevance here, has absolutely nothing
in common with the language theory concept of "monitor". It's just a
condition variable, recursive mutex, and arbitrary unassociated
application data, with some bad semantics and a really stupid attempt to
misuse a well known label for base advertising purposes. ("Java
monitors: 100% buzzword compliant.")
And I LIKE Java, I really do. But they deliberately ignored the
knowledge and experience of POSIX and their own UI threads development
and use, not to mention, as Szabolcs pointed out, 25 years (and that
number is actually being pretty generous) of computer science research,
in what I can only interpret as a superficial attempt to seem "cool".
Chris Thomasson
news:g23chj$c77$1...@usenet01.boi.hp.com...
It would be foolish of me to give a critique on Java because I rarely make
use of it. Back when I used to create socket servers and daemons for
different platforms, I found that Java was perfect for rendering portable
GUI applications which the system administrators could use to control
various aspects of the services. (e.g., set connection limits, view server
status, tweak various settings which deal with load and/or memory usage,
ect...). I have to admit that I did not use Java to create multi-threaded
applications.
> Szabolcs very definitely has an "agenda" with respect to language support
> for threading, and can pursue it extremely and abrasively. And I've
> already put in more than enough digs about the past history of a certain
> well known citizen of this forum that I won't do it again, but you know
> what I mean,
Oh yes. Indeed I do.
> and let's accept that as at least suggesting a possibility that Szabolcs,
> too, might eventually become a member of polite society.
I believe that he can be a great asset to this group. AFAICT, he only really
need to try and tone down the seemingly constant condescending tone that is
scatter across a plurality of his posts. He is definitely NOT stupid! It
just seems like he kind of "enjoys" attempting to make others who may
disagree with him on certain issues feel stupid... Does that make sense?
> In the case of Java, he's simply right.
I don't disagree with that. Mainly, I was just wondering what alternative
language he would suggest over Java.
[...]
Dave Butenhof
>> subject of Java "monitors" I agree 100% with Szabolcs, and very nearly
>> wrote essentially the same response myself when I saw the parent
>> post's reference to Java. (I overlooked it both because I saw the
>> reference as incidental to the post and also because I've discussed my
>> "issues" with Java synchronization often enough before... but I can't
>> let this one go by.)
>
> It would be foolish of me to give a critique on Java because I rarely
> make use of it. Back when I used to create socket servers and daemons
> for different platforms, I found that Java was perfect for rendering
> portable GUI applications which the system administrators could use to
> control various aspects of the services. (e.g., set connection limits,
> view server status, tweak various settings which deal with load and/or
> memory usage, ect...). I have to admit that I did not use Java to create
> multi-threaded applications.
Yep. Coding in Java makes you appreciate how stupid the C++ object model
is. (Not that C++ doesn't also have advantages; but on the whole I find
it much easier to "think in Java".)
And as trivial and superficial as the semantic synchronized tag is in
fact, it sure can be convenient to use and works just fine within its
design limitations. It's just that if you need to use wait, beware of
the 'spin out' unlocking design bug. Programmer discipline to avoid ever
nesting lock scopes, or to be absolutely certain that all predicates are
"clean" before entering a nested scope, is absolutely critical -- and
the language is completely unaware if you mess up while making it
absurdly easy to do.
>> and let's accept that as at least suggesting a possibility that
>> Szabolcs, too, might eventually become a member of polite society.
>
> I believe that he can be a great asset to this group. AFAICT, he only
> really need to try and tone down the seemingly constant condescending
> tone that is scatter across a plurality of his posts. He is definitely
> NOT stupid! It just seems like he kind of "enjoys" attempting to make
> others who may disagree with him on certain issues feel stupid... Does
> that make sense?
Absolutely. His sole response to any disagreement is "you don't know
what you're talking about because I, by definition, know all". It's a
counter-productive defense reaction that just makes him seem stupid. But
you're right, he clearly isn't; he just acts that way. He makes himself
his own worst enemy.
>> In the case of Java, he's simply right.
>
> I don't disagree with that. Mainly, I was just wondering what
> alternative language he would suggest over Java.
Sure; the challenge was just unnecessarily argumentative in this case.
("Worthy [...] for its holiness"???) Still, a good point. It'd be
interesting to know. If he's ever mentioned "the" language that embodies
his perfect threading model, I don't recall it. Possibly lost in one of
the long rambling tirades of insults that my brain just barfed on.
ppi
> is.
Can you be more specific please ?
That's not the first time I hear that kind of statement and I am just
curious of the argumentation (I code using both languages, so do not
hesitate to use language constructs to illustrate a given point).
And no, I am not interested in a language flame war, just curious
about the argumentation.
Since this is slightly out of topic ;-) feel free to make private
replies.
cheers,
-- paulo