Re: VO (and other libraries) & Threads

[Ian Rae <ianrae@istar.ca>]

----------
> From: Tim Teulings <tim@edge.ping.de>
> To: ooc-list@informatik.uni-kl.de
> Subject: Re: VO (and other libraries) & Threads
> Date: Thursday, May 21, 1998 8:20 AM
> 
> <snip>
> 
> Yes. But what I wanted to clarifiy is, that, while this is possible,
> the interface to X11 is rather huge, due to support for colors, fonts,
> windows and nummerous drawing primitives. This means, that there is a
> huge number of methods to be serialized/proteced. Java - a far as I
> remember - supports serialisation as a keyword of a class (the virtual
> engine will than do the protection) but in VO we had to put that code
> explicitely in, resulting in code bload and less readable and simpler
> code. We also would make VO dependend from a special thread library,
> which offers us the primites for thread ahandling. This will make VO
> less portable.

One approach that avoids having to protect each method is to limit
access to the display object.  The display object contains all the methods
for setting fonts, colours, drawing primitives, and so on.  Any code
wishing to use the display must call a special routine to get temporary
ownership of the display object.  Other routines that try to claim the
display object will be blocked until its released by its current owner.

On the issue of thread-safe libraries, it's also necessary that methods
be "re-entrant" -- that is, they only use local variables or variables
passed 
to them as function arguments.  They may not reference module-level
variables, at least not without a mutex.

This is of special importance in linked lists, which Oberon code tends
to use quite a bit.  Modifying another object's member variables is
not thread-safe since another thread may be doing something to that
object at the same time.

> 
> Note also that this is not the ultimate solution. As told, VO uses the
> model-viewer paradigm at some places. Diverent threads now can
> manipulate these models at the same time resulting in object state
> inconstencies when not proteced by semaphores. This increases the number
of
> interfaces again (and I had mentioned other interfaces, too). The
> question is: Should we protect at all, and if so, which interfaces
> should be proteced and which not? Or is the huge number of unserialized
> interfaces a design problem and should we fix it in general? Of couse
> the last one it a rather academic question, since I will not totaly
> rewrite VO. How do OSs or other languages (I mentioned Java, but what
> about smalltalk using MV paradigm, too) solve this problem?
> 

I've been reading comp.programming.threads for a couple of months and it's
clear
there are a lot of issues with threads.  Such as:

-core files and many UNIX debuggers only provide info on the main thread
-WinNT's implementation of POSIX is poor -- Microsoft engineers themselves
 reportedly recommended not using it!
-the interaction of threads and C++ is not at all a solved problem yet. 
Best
 quote of the month "C++ and threading -- welcome to a life of pain."
-multiple CPUs adds even more issues -- search the newsgroup in DejaNews
for
 "word-tearing".
-multiple-threaded software is difficult to test because the software's
behaviour
 becomes non-deterministic.  Safety-critical software projects have
rejected it 
 for this reason alone.

On the good-news side POSIX threads seems to be a good choice.  It's
widely available and there are some good books (Dave Butendorf's for 
example).  And the real solutions to safe and simple multi-threading
are those like Active Oberon where it's built right-into the language
and removed from direct programmer control.

--Ian