Re: Concurrency

[Ken Raeburn <raeburn@raeburn.org>]

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