[GBBopen-developer] Portable threads fix for SCL

[Dan Corkill]

> The 'without-lock-held implementation is not correct for the SCL.  This macro looks
> problematic. A throw from within does not re-acquire the lock so unsafe code could
> execute in the outer context. 

Douglas is correct about the throw/error situation.  WITHOUT-LOCK-HELD was
added originally to meet a specific user requirement for a very lightweight
means of temporarily releasing and then re-acquiring a lock (and this
should have been highlighted in its Reference Manual entry).  In hindsight,
the lightweight-performance requirement was less important than "safer" and
more expected semantics, so WITHOUT-LOCK-HELD has now been changed for all
platforms.

> Using 'unwind-protect may help, but a lock [re-]acquired
> in a cleanup could be hard to debug.

A possibility, but probably outweighed by the "safer" semantics--adding a
debugging UNWIND-PROTECT around the forms within the WITHOUT-LOCK-HELD
could be used to check what is happening in a really strange situation.

> Further the whostate for the original lock
> acquisition is not available within the locked context on the SCL, or CMUCL, and it is
> only set when waiting for the lock; is it actually set in this context on other CL
> implementations?

Whostate management by Portable Threads for CMUCL and SCL needs more
attention (a broader issue than the WITHOUT-LOCK-HELD form).  Only CLs that
support a means of setting a thread's whostate value maintain all
Portable-Threads-specified whostate values.  On other CLs, the Portable
Threads interface tries to do the best that it can by using the CL's forms
that provide whostate options (if any).

> Some more changes may be necessary for the SCL and I'll follow up soon.

The Portable-Threads-internal definition of %%LOCK-RELEASE needs to be
checked (and possibly redefined) for SCL.

Previously, GBBopen support on SCL was generously performed by Douglas, but
changes/testing to new GBBopen releases (such as the introduction of
WITHOUT-LOCK-HELD) remained suspect until the latest GBBopen could be
checked/tested by Scieneer.  Scieneer's exciting new policy for
non-commercial user should help change this situation.

-- Dan

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.