Re: Lispm stuff

[Todd.Kaufmann@NL.CS.CMU.EDU]

> So when you call mutex-lock or event-wait you can supply a string.  Is that
> string associated with the thread or the mutex/event?  If it's associated
> with the thread, then it can be easily extracted as a second return value
> of thread-status.  If the lock, then there are problems, because many
> threads can be trying to lock the same mutex.

If a thread is waiting for a lock, then that should be in it's status.
When the mutex is (finally) locked, the winner's name (the locker) should
be in there.  Otherwise, there won't be anyway to understand the connection
between these objects (for debugging purposes).

re: the lock:  it doesn't matter who wants it, it's who's holding it that
counts.  The others clamoring for it can put that in their name (or :whostate).


Consider this example under Allegro:


 <cl> (setq l0 (mp:make-process-lock :name "Lock l0"))
 #<process-lock Lock l0 @ #xa194be> 
 <cl> (mp:process-lock l0 'me "I got it..")
 ME 
 <cl> l0
 #<process-lock Lock l0 @ #xa194be locked by ME> 
 <cl> (mp:process-run-function "lock test" 
	 #'(lambda (lock) 
	     (mp:with-process-lock (lock)
	       (format t "~&My lock now: ~s.~&" lock)))
	 l0)
 #<process lock test @ #xa1a3ce>

 <cl> :proc
 "lock test" is Lock (arrested for #<process-lock Lock l0 @ #xa194be locked by ME awaited by #<process lock test @ #xa1a3ce Lock>>).
 "Initial Lisp Listener" is active.

 <cl> (mp:process-unlock l0 'me)
 NIL 
 <cl> 
 My lock now: #<process-lock Lock l0 @ #xa194be locked by #<process lock test @ #xa1a3ce>>.

 :proc
 <cl> "Initial Lisp Listener" is active.
 <cl>


A lock is usually locked by a process (and value is by default the process),
but it can have any value.  Anyone knowing the name of the lock has the
power to unlock it.

 -todd