File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Threads and Synchronization and the fly likes clarification about java's support for concurrency Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "clarification about java Watch "clarification about java New topic
Author

clarification about java's support for concurrency

Tim McGuire
Ranch Hand

Joined: Apr 30, 2003
Posts: 820

I'm trying to find clarification, not nitpick. I keep reading that java doesn't have "true" Monitors because
1) no explicit queues
2) compiler can't assure that all fields capable of being accessed by multiple threads are protected by monitors

but I'm trying to nail down the dates for these statements and it is very hard to know which version they are referring to.

The reason I'm reading about this is just to understand why on Wikipedia they argue that java doesn't "really" support concurrency.

and to see if the following statement is still true:

Java’s most serious mistake was the decision to use the sequential part of the language to
implement the run-time support for the parallel features
.
In 1975, Concurrent Pascal demonstrated that platform-independent parallel programs (even
small operating systems) can be written as a secure programming language with monitors. It
is astounding to me that Java’s insecure parallelism is taken seriously by the programming
language community a quarter of a century after the invention of monitors and Concurrent
Pascal. It has no merit.


This is the document I'm reading: http://java.sun.com/developer/Books/performance2/chap4.pdf

so my real questions are, does java support concurrency even though it doesn't implement monitors correctly. is there a plan for java to support a "true" monitor? and.... Do you believe the java monitor is sufficient?
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18717
    
  40

Not exactly sure how the articles reach their conclusions -- in fact, it seems to be very weak to me.

The core of the argument is that Java doesn't support explicit condition variables -- which are notification queues that are attached to locks. There are two problems with this argument.

1. It is very easy to implement condition variables with the standard synchronization (and wait and notify) mechanism.

2. And if you don't want to implement them. Java 5 added lock and condition variable support as part of the core.


Not saying that you are nitpicking, but the articles that you are presenting seems to be -- unless, of course, there is another interpretation that can be derived from the article, that I am missing.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18717
    
  40

In reading this topic a bit more... I feel that I need to make another point. Particularly aimed at the "astounding" argument.

Java’s most serious mistake was the decision to use the sequential part of the language to
implement the run-time support for the parallel features
.
In 1975, Concurrent Pascal demonstrated that platform-independent parallel programs (even
small operating systems) can be written as a secure programming language with monitors. It
is astounding to me that Java’s insecure parallelism is taken seriously by the programming
language community a quarter of a century after the invention of monitors and Concurrent
Pascal. It has no merit.


This is true for any API based library -- as the threading (and the synchronization) are cooperative. There are no guarantees that are mandated by the language. This means that the Windows threading system, the POSIX threading system, and Solaris threading system, also has the same issues.

What I find "astounding" is that the author feels that concurrent pascal should be "taken seriously" as the standard for threads, using an argument that the thread model is faulty, when the most common OSes, Windows (Windows threads), Linux (POSIX threads), and the System 5 based Unixes, such as HP-UX, AIX, and Solaris (Solaris threads) -- not to mention the large amount of Java applications -- all have the same so called fault.

Now, of course, the quote in this topic may be taken out of context -- so this augument may be unfair to the quoted author (from Wikipedia).

Henry
Tim McGuire
Ranch Hand

Joined: Apr 30, 2003
Posts: 820

Thanks. This helps clarify things.

a final question is why doesn't the java compiler warn us if there is a combination of synchronized and non-synchronized methods in a class and they access the same resources, you can have problems, as this excellent article by Alex Miller describes

his example code:


There are some tools (IntelliJ and findbugs) that will warn you about cases like this. I can't say that a java compiler should or shouldn't give a warning or an error in these cases, because I truly do not know. I'm trying to track down the thinking behind this to understand when and where the decision was made.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18717
    
  40

There are some tools (IntelliJ and findbugs) that will warn you about cases like this. I can't say that a java compiler should or shouldn't give a warning or an error in these cases, because I truly do not know. I'm trying to track down the thinking behind this to understand when and where the decision was made.


Well, if you want to know "why", you are going to ask the designers directly... But I think that they got it right. The compiler is mainly responsible for the syntax, and what you are referring to is the API. For the compiler to catch what you have in the example, it will have to be coded with knowledge of the libraries which is kinda silly.

And even if it was done, it wouldn't be able to do third party libraries, or even classes in your program.

Henry
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: clarification about java's support for concurrency