Re: Concurrency

[Ken Raeburn]

On Mar 29, 2010, at 11:37, Tom Tromey wrote:
> I think it would be better to have all mutexes be recursive, because it
> is safer.

I can see some desire for recursive mutexes, but I lean towards Butenhof's view 
myself.  If all mutexes are recursive, I'd like a way to find out if I've 
already got a mutex locked, so I can manually detect when I've screwed up my 
locking model, even if someone else wants to use recursive mutexes in their 
code.

BTW, one extension I'd suggest is an optional timeout for mutex-lock: nil would 
mean block until the lock is acquired, a positive number would mean wait up to 
that long (e.g., pthread_mutex_timedlock), and a non-positive number would mean 
try to acquire the lock but don't wait.  I'm not sure offhand if failure to 
acquire the lock should be indicated by throwing an error or a return value; 
I'm leaning a little towards throwing an error.

If this really catches on, read/write locks will probably be wanted too, but 
they can be built on mutexes and condition variables initially, and moved into 
C code later if they're really helpful and performance-critical.

For debugging, I think I'd want a way to check whether a particular thread has 
locked a mutex.  Not a predicate someone might be tempted to use for 
non-debugging purposes, more like an assertion that throws an error when false.

> Also, I think mutex-unlock should throw some kind of error if the mutex
> is owned by a different thread.  What do you think of that?

Probably the best thing -- and likewise if the mutex isn't locked at all.

Ken