Boost logo

Boost :

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: (+386 1) 586 53 49     fax: (+386 1) 586 52 70

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk