Re: Not keen on Boost.Threads? [was: name of the "thread" type]

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-07-05 04:58:21

> > > > http://www.acm.org/classics/feb96/
> > > >
> > > > "Monitors: An Operating System Structuring Concept
> > > >  C.A.R Hoare..."
> > >
> > > Thanks. This seems to be another case of me reinventing the wheel. :
-)
> > > What he's describing there seems to be the concept I put in my thread
> > > library under the name Flag.
> >
> > i do not think so.. condition variables are stateless and
> > they are working together with mutex providing atomic
> > unlock_and_wait semantics (with respect to other threads
> > and CV/mutex).
>
> I meant that my Flag == his Monitor, not Flag == CV. If you disagree,
> please explain what the difference is.

your Flag/RWL/... can be implemented as a monitor
(which is shown in the paper, see example below).
however, your Flag CANNOT be used to implement the
MONITOR CONCEPT. mutex and condition variable(s)
is needed to implement monitor concept. in fact,
the only correct usage of CV is the implementation
of monitor concept -- everything else is _incorrect_.
monitor is:

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

...a collection of associated data and procedures is known
as a monitor; and a suitable notation can be based on the
class notalion of SIMULA67 [6].

monitorname: monitor
  begin ... declarations of data local to the monitor;
    procedure procname ( formal parameters . . .);
      begin ... procedure body ... end;
      ... declarations of other procedures local to the monitor;
      ... initialization of local data of the monitor ...
  end;

[local data is protect by mutex]

...Otherwise, if two procedure bodies were in simulatenous
execution, the effects on the local variables of the monitor
could be chaotic. The procedures local to a monitor should
not access any nonlocal variables other than those local to
the same monitor, and these variables of the monitor should
be inaccessible from outside the monitor.

...In many cases, there may be more than one reason for
waiting, and these need to be distinguished by both the
waiting and the signalling operation. We therefore
introduce a new type of "variable" known as a
"condition"; and the writer of a monitor should declare a
variable of type condition for each reason why a program
might have to wait. Then the wait and signal operations
should be preceded by the name of the relevant condition
variable, separated from it by a dot:

condvariable.wait;
condvariable.signal;

Note that a condition "variable" is neither true nor false;
indeed, it does not have any stored value accessible to the
program. In practice, a condition variable will be
represented by an (initially empty) queue of processes
which are currently waiting on the condition; but this
queue is invisible both to waiters and signallers.

As the simplest example of a monitor...

[binary semaphore/exclusive lock/auto-reset event]

single resource:monitor
begin busy:Boolean;
     nonbusy:condition;
  procedure acquire;
     begin if busy then nonbusy.wait;
              busy := true
     end;
  procedure release;
     begin busy := false;
           nonbusy.signal
     end;
  busy := false; comment inital value;
end single resource;

> > note that auto-reset event is simply a binary semaphore.
> > manual-reset events also have state. it is really difficult
> > to use events due to all sorts of race conditions with
> > respect to "program" state and event state.
>
> I keep seeing assertions to that effect, but I've never seen any attempt
> to justify the claim. Could you please supply a logical argument instead
> of a bare take-my-word-for-it? (Your example using my RWL doesn't count;
> I did say it was newly written and poorly tested, I expected it to still
> have some bugs.)

well, the point is that in your POSIX version
of RWL (which implements monitor concept) you do
not have that bug. if that fact does not convince
you that "it is really difficult to use events"
and "Events are much more error prone", i really
do not know what you are looking for as a better
way to "justify the claim".

regards,
alexander.