semaphores between processes

[Daniel Eischen]

On Fri, 23 Oct 2009, Andrew Gallatin wrote:

> Daniel Eischen wrote:
>> On Fri, 23 Oct 2009, Andrew Gallatin wrote:
>> 
>>> It would be great if they were, but that discussion was 6 months
>>> ago, and nothing seems to have happened.  Plus we need to support
>>> at least 7.X and probably 6, so any changes here might not even
>>> help us.
>>> 
>>> What is wrong  with just using umtx directly?  It seems to do
>>> exactly what we need.
>> 
>> Because you can't do anything more than use umtx directly,
>> like check for mutex types and return appropriate error
>> codes.  Just look at other implementations - Solaris,
>> Linux, all have their pthread_*_t as public structs.
>
> I'm not saying that having pthread*t public, and getting all
> the features of real PTHREAD_PROCESS_SHARED would not be far
> better in general.  But in this case all we need is a lock around
> a shared resource.  Eg, nothing fance.  So our choices seem to be
> either:
>
> 1) use sysv semaphores (ick)
> 2) use a hand rolled spinlock (ick)
> 3) use some sort of hack built into our driver (ick, ick)
> 4) use umtx
>
> Is there some bug or limitation in umtx that makes it inappropriate?
> (beyond the obvious, like the potential to leave a resource locked
> forever if the lock holder exits).

We already use umtx.  This really is a hack and I wouldn't
advocate it.  I'm not sure how you could make it work and
not break existing ability to return appropriate error
codes without slowing down the path in the non-shared
case.  You'd have to check to see if the address space
was shared or not, which would require a system call.

All our public pthread_foo() symbols are weak.  You
can easily override them in your application code in
the #ifdef freebsd case.  What is wrong with providing
your own library that overrides them to do what you
require - this shouldn't change your application code?

-- 
DE