Re: About synchronization methods

Chris Thomasson wrote:
"Szabolcs Ferenczi" <szabolcs.ferenczi@xxxxxxxxx> wrote in message news:bc354f8c-c13a-4e85-9b2e-7cbfb9abe155@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Jun 3, 10:07 am, Surinder Singh <Surinder.Si...@xxxxxxxxxxx> wrote:

> 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

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?

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".
.

Relevant Pages

  • Re: atomic operations...
    ... No MUTEXS! ... the Monitor class in .NET isn't strictly speaking a Windows mutex function). ... Until you've measured and confirmed a genuine performance problem, IMHO you should not care so much about the specific synchronization mechanism used. ... The Java implementation trades synchronization in the class itself for synchronization in the memory manager. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Security-oriented languages (was: Privilege-escalation attacks)
    ... > Of course synchronization has to be used properly. ... > dust could a language apply to protect multithreaded code that doesn't ... be assured by the language. ... >> anyone make a good case that Java is more suitable for writing secure ...
    (comp.security.misc)
  • Re: Security-oriented languages (was: Privilege-escalation attacks)
    ... > Of course synchronization has to be used properly. ... > dust could a language apply to protect multithreaded code that doesn't ... be assured by the language. ... >> anyone make a good case that Java is more suitable for writing secure ...
    (comp.os.ms-windows.nt.admin.security)
  • Re: Block in synchronized mathod
    ... Where are those coming from in a Java ... malice, or possibly by design. ... but using coarse-grained monitors when you're waiting ... (remember you can use any old Object as a monitor). ...
    (comp.lang.java.help)
  • Security-oriented languages (was: Privilege-escalation attacks)
    ... >> of Java that help in writing secure applications. ... > language with bounds checking should fit the bill. ... > (synchronized code helps protect what's in the app, but only if you use it ... Of course synchronization has to be used properly. ...
    (comp.security.misc)