[Ecls-list] Mutex & fairness

[Juan Jose Garcia-Ripoll]

On Wed, Mar 28, 2012 at 3:25 AM, Daniel Herring <dherring at tentpost.com>wrote:

> The exact same issue occurs with condition variables.  As a result, the
> caller of pthread_cond_signal frequently needs to use the same mutex as the
> caller of pthread_cond_wait.
>

Yes, I know, but condition variables are really not a good primitive type.
They are not portable and they already involve two system objects: mutexes
and the variable itself.


> Random idea; I don't like it; but maybe it will spark a good one. If ECL
> spawned a dedicated "kernel" process


I have thought about it. We already have an extra thread for signal
handling, and could be reused. But if possible, then this thread should be
sleeping as long as possible, because that one might end up being the CPU
hog.


> Another idea.  I've seen a people advocate using UNIX sockets as a
> synchronization mechanism in some circumstances.  Write a byte as a signal.
>  The receiving process can use a blocking read() and still be woken by
> interrupts.  Different efficiency tradeoffs than the polling loop.  Harder
> to get lost between 1 and 2, but introducing other problems.
>

Sounds like a reasonable compromise, but would require one socket per mutex
at least.


> Can't you use pthread_mutex_trylock to query whether a thread is locked?
> Not super efficient, but it should work.
>

The problem is not really to know whether the mutex is locked, but whether
it is locked by our thread. Think of a call to WITH-LOCK. It relies on
pthread_mutex_lock() but the call gets interrupted and it jumps out of the
system routine with THROW, RETURN, etc. How does WITH-LOCK know whether it
has to release the lock? Checking with trylock does not work because
another thread might have locked in the time that passed between the
interrupt and the actual check.


> Similarly, might it be possible to use pthread_mutex_timedlock, and use it
> in a polling loop to check whether any interrupts have been delivered?
>

This ends up being like our atomics implementations where the atomics and
the nanosleep() are packed together.


> In these issues, I sometimes think the user's expectations cannot be
> satisfied, and that they really need something slightly different than what
> they are asking for.  Could you remind me of the thread where this
> interrupt/mutex issue came up?  Is it basically the clean shutdown /
> "Control-C" to wake a hung process issue, or something deeper?


Basically it is the expectation that Common Lisp processes can be
interrupted, that a thread can be killed and that during interactive
development one may stop a blocking process that is waiting on a mutex.
Things like these. In other worlds (C/C++), these requirements do not exist
because programs are simply killed, debugged and restarted.

I myself would live much more happily if all the Lisp interrupt business
disappeared, but it is out there and making ECL be the only implementation
that does not support them would be like shooting on our own feet.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20120328/ce4ac105/attachment.html>