On May 20, 11:45 pm, gpderetta <gpdere...@gmail.com> wrote:
think about a language like java, which has explicit
synchronized {} blocks. Certainly, by all definitions, this
is language support for threading (even if I'm sure it doesn't fit
your vision of good language threading support).
The `synchronized {} blocks' are language support for specifying
Critical Regions but, you are right, it is not correctly defined in
Java.
Let's consider a little variant of java/c++ hybrid with a
builtin mutex type, where the synchronized block take
the mutex explicitly as a parameter (instead of implicitly
like in java), and obvious semantics.
mutex m;
...
synchronized(m) {
// do something in mutual exclusion
}
So far so good.
So far not so good at all.
1) First of all the mutex is a library level tool. It is not a
language tool. It shall not appear at the language level. The mutex is
part of the library-based solution for achieving mutual exclusion of
the processes. There can be various language means for specifying
Critical Region, and one of them is the `synchronized' keyword.
However, it is not about the keyword, since you can call it
`synchronized', `region', `cr', or whatever. The main issue is that if
it is a language level means, it has consequences, see the semantics.
One important semantical issue is that the block marked by this
keyword may contain access to shared variables and access to shared
variables can only appear in these kind of blocks. Note that the low
level mutex can be inserted by the compiler to implement the Critical
Region defined at the language level. On the other hand, the high
level Critical Region can be implemented by any other means in the
compiler as far as it ensures mutual exclusion. That is one of the
benefit of a high level language.
2) In procedural languages if you introduce a keyword for a Critical
Region, you must also give some means to associate which shared
variables are involved. So, fixing your example, if there is a shared
resource `m' you can define a critical region using a keyword like
`synchronized' such as this:
shared int m; // the `shared' keyword marks the shared variable
...
synchronized(m) {
// here you can access `m'
}
Now the compiler can make sure that `m' is accessed within Critical
Regions and only within Critical Regions.
Can you see the difference between the language level means and the
library level means?
3) In object-based or higher level object-oriented languages the unit
of shared resource is obviously an object. So the association of the
Critical Region and the critical resource is naturally merged in an
object. That was one of the failure of Java that they were not brave
enough to mark the class as the shared resource. In a decent
concurrent object-oriented language you could specify a keyword for
the class to mark a shared object (and not for the methods). E.g.:
synchronized class M {
int m;
public:
void foo() {
// do something with `m' in mutual exclusion
}
};
You must mark the class as a whole and not the individual methods of
it. Then the compiler can again help you to make correct concurrent
programs. This is again not possible with library-based solution.
I'm not sure marking the class like that is a good idea. Would you