Re: [boost] Threads

From: Greg Colvin (greg_at_[hidden])
Date: 2000-08-05 17:02:28

> From: Branko Cibej <branko.cibej_at_[hidden]>
> Greg Colvin wrote:
> > Java did a truly terrible job of it, in my opinion.
> 
> I've seen this sentiment expressed before on this list. Not having
> had any real Java experience, I'd be very interested in having it
> explained in a bit more detail, if only to prevent similar mistakes
> cropping up here. Could you describe Java's problems a bit, please?

My observation is that even skilled progammers get into lots
of trouble with Java threads.  I suspect that is because the
concurrency primitives in Java are too primitive.  Java claims
to have implemented monitors, but a comparison to Hoare's
classic paper shows that they fall short:

http://www.acm.org/classics/feb96/

Further discussion can be found (not online, sorry) at

  Java's Insecure Parallelism
  PER BRINCH HANSEN
  ACM SIGPLAN Notices 34,4 (April 1999), 38-45

  "The author examines the synchronization features of Java 
  and finds that they are insecure variants of his earliest 
  ideas in parallel programming published in 1972-73.  The 
  claim that Java supports monitors is shown to be false.  
  The author concludes that Java ignores the last twenty-five 
  years of research in parallel programming languages."

We could do worse than to provide proper monitors in Boost.
a sketch of an implementation can be found in

http://csshaun.cs.ru.ac.za/osnotes/osnotes007.html

which I quote here:

7.5.2   Monitors

A Monitor is an abstract data type, i.e. a combination of data structures and 
operations, where at most one operation may be executing at one time. The required 
mutual exclusions are enforced by the compiler implementation of the monitor, using 
some of the synchronization primitives described in section 7.3. 

Monitors were introduced to simplify the writing of concurrent programs since the 
direct use of spinlocks and semaphores tended to result in programs that were hard 
to write correctly. Though monitors were intended for use as language constructs 
when programming in languages such as Concurrent Pascal, or Concurrent Euclid, and 
now in Ada95 and, in a simplified form, in Java, monitors, as an idea, can be used 
very conveniently in our concurrent programs written in C and using Unix system 
services. 

A Monitor is not a process, nor an active entity. It is just an abstract data type, 
or class, whose code can be executed by only one process at a time. 

The principle idea behind a monitor is the concept of a built-in mutual exclusion 
operator provided by the system. A standard C++ class can be converted into a 
monitor using this mechanism:

  class MyClassNowAMonitor
  {
    private: 
      Mutex mutex;
    Method1 ()
      {
        mutex.lock ();
        ..do what ever Method1 normally does
        mutex.unlock ();
      }
    Method2 ()
      {
        mutex.lock ();
        ..do what ever Method2 normally does
        mutex.unlock ();
      }
    Method3 ()
      {
        mutex.lock ();
        ..do what ever Method3 normally does
        mutex.unlock ();
      }
  }; 

The significant changes to the class involve the addition of the mutex operator, 
and the protection of every method by the single mutex.

Within a monitor it is possible to use a special operator, called a condition 
variable. Its operations are usually called wait, and signal. 

When condition variables are used within monitor procedures, they are used only to 
allow processes that do not want to continue at this point, to get out of the way 
to allow other processes to run. 

The wait operation on condition variables always puts to sleep the process that 
executes it. But before going to sleep, the condition variable unlocks the mutex, 
and relocks it once it re-awakes. The signal operation on condition variables is 
null if there is no process currently waiting on that condition, otherwise it wakes 
one of the waiting processes. The code for the wait and signal operations of 
condition variables need not be protected as critical regions because only one 
process is executing in the monitor at a time. 

The implementation of a condition variable would look something like:

  class ConditionVariable
  {
    Queue of processes: Q;    
    ConditionVariable ()
      {
        // constructor
        set Q to be empty.
      }

    wait ()
      {
        mutex.unlock (); // unlock the mutex of the monitor.
        add current process to Q.
        suspend current process.
        mutex.lock ();
      }

    signal ()
      {
        if Q is not empty then
          take a process off Q
          add the process to the ready list
      }
  }; 

----- Original Message ----- 
From: Branko Cibej <branko.cibej_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, August 04, 2000 10:26 PM
Subject: Re: [boost] Threads

Greg Colvin wrote:
> Java did a truly terrible job of it, in my opinion.

I've seen this sentiment expressed before on this list. Not having
had any real Java experience, I'd be very interested in having it
explained in a bit more detail, if only to prevent similar mistakes
cropping up here. Could you describe Java's problems a bit, please?

    Brane

-- 
Branko Cibej                 <branko.cibej_at_[hidden]>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
voice: ([phone]     fax: [phone]