thread design

[William.Lott@ARDATH.SLISP.CS.CMU.EDU]

Okay, I've incorporated the responses I've gotten from Rob and Chris.

>     make-thread(function &key stack-size initially-suspended) => thread
> 	Creates a new thread that will initially call FUNCTION.
> Should have a :NAME arg.  Probably :PLIST too.

Okay.

>     thread-self() => thread
> 	Return the thread object for the currently running thread.  ### Make
> 	this a special instead?
> I'd say leave it as a function, though we might well want to implement it
> as a special reference.

Okay.

> thread-exit(value) => nil
>    Terminate the current thread.  Acts as if the initial function return
>    returned with VALUE.  Unwind-protects *are* processed.
>    ### Do we want to offer a facility to ignore unwind protects?
>
> I don't really think so.  Common Lisp doesn't provide any way to sleaze out
> of unwind protects.  If someone really needs to do it, they can grab the
> Mach thread and do the appropriate syscall.

Okay.

> A note about thread values.  If this mechanism is really going to see much
> use, then it would be nice if it supported multiple values.  If it would be
> too complicated, we can blow it off, but all of the analogous mechanisms in
> CL allow multiple values.  It would seem that thread creation is a
> sufficiently expensive process, that automatically bundling return values
> into a list wouldn't be prohibitively expensive.

Okay.  I changed ``thread-exit-value'' to ``thread-results'' to make the
mv-ness more obvious.  Besides, I never liked the name thread-exit-value.

> There seems to be a missing operation here, too.  There is no way to
> iterate over all the threads.

How about:

do-threads((var &optional result-form) &body body)

>    thread-suspend(thread) => boolean
>    thread-restart(thread) => boolean
> What is the meaning of these return values?  A success code?  That isn't
> very Lispy.  Would these operations normally ever fail if the program
> wasn't broken?

I don't remember what I was thinking then.  Okay, no return value.

> thread-kill(thread) => boolean
>     Zot the thread.  ### what about unwind-protects?
> 
> Well, that is an interesting question.  My guess is that this operation (or
> at least some operation) should just blow the sucker away, since we need
> some sort of mechanism for nuking wedged threads.

How about an optional process-unwind-protects?

> But it seems that we also need some process control operations not in
> cthreads.  For example, THREAD-DEBUG, which invokes the debugger on a
> thread (stopping it.)  And perhaps THREAD-SIGNAL, which would signal an
> arbitrary condition in another thread.  Maybe also THREAD-RESTART, which
> invoke a restart case.  The debugger will also need internal primitives for
> picking apart the state of stopped threads.

I haven't put much though into this area, but I assumed that we would have
to have something along those lines also.  I figure the first step is
getting the underlying support.


>     make-mutex(&optional name)
> 	Create a new (unlocked) mutex.  
> When designing new interfaces, I have a rule to always use keyword args
> over optionals unless it is blindingly obvious that the function will
> never want any new arguments.  At least to me, it is not blindingly obvious
> here.  For example, we might want to add a :DEBUG option that tells the
> system to keep track of more information, such as which thread has it
> locked, and to do more error checking.

Okay, the name is a keyword.

> mutex-lock(mutex)
>     Attempt to lock the mutex, and block until you can.  Note: no attempt
>     is made to protect against the case of a single thread attempting to
>     lock a single mutex twice (which will deadlock it).
>
> Is there some reason why this error check is not possible?  If it is
> possible, then should at least have a debugging mode that does the error
> check. [Ditto for MUTEX-UNLOCK]

There is no reason my it can't be done, but there are two reasons by I
don't want it done: it is not necessarily an error, and it would slow it
down.  There are some synchronization paradigms that involve doing things
like unlocking a mutex that someone else has locked.  You can implement
co-routines in this manner.  Besides, if you want a ``safe'' lock, you can
easily build it out of unsafe locks.

> As for conditions, the name is clearly a total loss, since CL already has
> conditions.  I also don't know what cthreads conditions are.  Perhaps you
> could give a brief description?

Oops.  I've changed the name to event.  I'll post a summary about how to
use events in a bit.  (I want to get this message out before too long.)

-William

ps: My up-to-date interface description is in:
	.../new-compiler/wlott/work/threads.txt