A mutex for inter-process ;-)
deischen at freebsd.org
Tue Mar 31 06:12:04 PDT 2009
On Tue, 31 Mar 2009, Randall Stewart wrote:
> On Mar 31, 2009, at 2:50 AM, Daniel Eischen wrote:
>> They define the API. We should not be making new APIs for something
>> that already exists, that applications already know how to use, etc.
> So what you are saying is ... just let the application do it. Provide
> nothing but the ability to "mark" a mutex as shared. And let the
> app figure it out.
Correct. We do not need nor want any more SYS V IPC
stuff and have more utilities like ipcrm, ipcs, etc
to deal with them. POSIX already defines the API for
us and tells us how to use process shared mutexes, et al.
> Hmm.. If one company is asking for this ability i.e. easily
> do shared mutexs I am sure other folks have wanted it as well.
> Now rolling your own is a valid thing to do.. but it seems to
> me providing something for general use is not a bad idea either.
There already is something for general usage, see
> The pages you pointed out even show such a mechanism for
> semaphores... i.e. there definition of
> semaphore_create(char *shared_name)
> semaphore_open(char *shared_name)
> and kin.
> Curious place for it though.. under pthread_mutex_destroy() ;-)
They are also in the POSIX spec under their own entries.
> And of course as pointed out this does not solve the quick death
> syndrome (for that matter neither did I yet but I am thinking
> about this one ;D)... which is the real hard problem.. and really
> does require assistance beyond what an application can generally
No, the kernel can do it under the existing umutex API.
You should really be asking David Xu this stuff, but
the kernel can remove any of its own resources (if it
has any allocated) when the shared memory is removed,
or it may be possible to have POSIX mutex robustness
by having the kernel unlock or deallocate umutex
resources upon process termination.
The point is, it is possible for the kernel to do this,
if it already doesn't, using the existing umutex APIs.
> IMO having a general library function available is a good thing. If
> you are not interested in seeing it in libthr where I think it would
> belong.. thats fine I can build a port or other such...
> I will send Julian the manual page after I get it built through :-D
There already is an API for doing what you want, and
sorry, but no, I don't think adding a BSD-only API
that is different from something POSIX already defines
is a good thing ;-)
More information about the freebsd-threads