Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 Oct 2009 13:18:02 -0400 (EDT)
From:      Daniel Eischen <deischen@freebsd.org>
To:        Andrew Gallatin <gallatin@cs.duke.edu>
Cc:        freebsd-hackers@freebsd.org, Christian Bell <christian@myri.com>
Subject:   Re: semaphores between processes
Message-ID:  <Pine.GSO.4.64.0910231316370.16693@sea.ntplx.net>
In-Reply-To: <4AE1D97F.6060708@cs.duke.edu>
References:  <4AE0BBAB.3040807@cs.duke.edu> <4AE0C995.5060303@cs.duke.edu> <Pine.GSO.4.64.0910221715330.11443@sea.ntplx.net> <200910230802.49873.jhb@freebsd.org> <Pine.GSO.4.64.0910231055270.16088@sea.ntplx.net> <4AE1CE31.1090206@cs.duke.edu> <Pine.GSO.4.64.0910231142330.16269@sea.ntplx.net> <4AE1D1D2.1090307@cs.duke.edu> <Pine.GSO.4.64.0910231158180.16269@sea.ntplx.net> <4AE1D97F.6060708@cs.duke.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 23 Oct 2009, Andrew Gallatin wrote:

> Daniel Eischen wrote:
>
>> 
>> 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.
>
> I'm probably missing something.  What does it matter if the
> address space is shared, as long as the umtx struct is
> in shared memory?
>
> From my quick read, the umtx operations use a lock word
> in userspace. For uncontested locks, they use atomic
> ops to flip an id into the lock word.  The kernel takes
> over for contested locks, and does sleeping, wakup, etc.
> Is this correct?  Is there something here that matters
> if the address space (and not just the lock word) is
> shared?
>
>> 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?
>> 
>
> For our code, I was thinking of something like:
>
> #ifdef FreeBSD
> #define lock(x) umtx_lock(x, getpid())
> #define unlock(x) umtx_unlock(x, getpid())
> #else
> #define lock(x) pthread_mutex_lock(x)
> #define unlock(x) pthread_mutex_lock(x)
> #endif
>
>
> I should probably just shut up and try it..

My apologies - I thought you were talking about changing
our pthread_mutex_* functions in src/lib/...

-- 
DE



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0910231316370.16693>