[804] in Coldmud discussion meeting

Multithreaded ColdC...

daemon@ATHENA.MIT.EDU (Mon Sep 11 16:15:32 1995 )

Date: Mon, 11 Sep 95 12:48:49 PDT
From: weber@tungsten.seattle.geoworks.com (Eric Weber)
To: 869683 Gillespie Brandon James <brandon@smithfield.declab.usu.edu>
Cc: coldstuff@MIT.EDU
In-Reply-To: <9509100226.AA02088@smithfield.declab.usu.edu>


I haven't paid a lot of attention to Cold for a long time, but I do
work with threads and synchronization a lot in other environments.  I
hope, therefore, that my comments are not completely useless :)

Gillespie Brandon James writes:
 > Or, the block control 'sync' can be used,
 > which accepts a list of objects and contains a block of code to execute
 > while synchronized to the object(s), such as:
 > 
 > sync (this()) {
 >     while (times) {
 >         .call_synced_method();
 >         times = times - 1;
 >     }
 > }

What kind of deadlock control do you have planned?  It's trivial to
ensure that two threads which each do a single sync cannot deadlock,
but if multiple instances of sync are used in the same thread deadlock
is possible.  Do you want the server to automaticly detect deadlock
conditions and throw an error, at some performance cost?

 > 
 > When a thread is synchronized with an object, it has full read/write
 > ability to any object variables it can access.  

Does this imply that an unsynchronized thread does not have full
read/write ability?

 > Furthermore, the synchronization is cooperative througout the thread.
 > If a synchronized frame calls a method which must be synchronized, it is
 > not blocked.

I wonder if it is ever going to be useful to have a non-cooperative
lock that generates an error if locked multiple times by the same
thread.  I use both types of locks at work, I'll have to think about
whether they apply in the cold environment.

 > If a synchronize call is made, and the thread is unable to synchronize
 > with the object, it may be blocked (if it is not atomic).  Blocked threads
 > are suspended, and added to a list for that object.  

What if you're synchronizing multiple objects, some of which are
locked and some of which are not?  I presume you want to sort the
objects by a global ordering and lock them in order.

 > When the
 > current thread synchronizing to the object releases it's hold, the first
 > thread in the blocked list is executed.  If a thread is blocked, and is
 > atomic, the error ~blocked is thrown.

What happens if the object is destroyed?

 > 
 > * Atomic code blocks
 > 
 > If a frame is preempted blocked or suspended while it is set as atomic,
 > the error ~preempted, ~blocked or ~suspended is thrown.  The atomic
 > state propogated through subsequent frames in the thread, so that if a
 > frame becomes atomic, while it is atomic any frames further down the
 > thread from it become atomic.

I haven't been keeping up with Cold development, but I assume it's
fairly easy to ignore errors, if you count ~preempted as an error.

 > * Function pause()
 > 
 > pause() gives the ability to cooperatively multh-thread.  It will have
 > an optional flag which can be passed (1 or 0), if it is true (1) then
 > pause() will act nicely, if it is false (default, 0) it will not act
 > nicely.
 > 
 > When pause() is called it will instantly preempt the thread, unless it
 > is within an atomic block.  If it is within an atomic block and is a
 > nice pause, the thread will continue to run until it either runs out of
 > frame ticks or it reaches the end of the atomic block.  If it runs out
 > of ticks, the usual error is thrown (~ticks).  If it reaches the end of
 > the atomic block it instantly preempts.

What happens when a non-nice pause is called inside an atomic block?

 > Notes: possibly have a MAX_FORK for each thread; 

What exact quantity would this limit?  The number of times a thread
can call fork()?  The number of direct children?   The size of the
subtree?  The depth of the subtree?

Other thoughts:

Do you plan any kind of message passing system?  Right now it appears
that the only kind of inter-thread communications possible is through
shared memory (i.e. object instance data).

-- Eric