Date: Fri, 23 Oct 2009 12:07:54 -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.0910231158180.16269@sea.ntplx.net> In-Reply-To: <4AE1D1D2.1090307@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0910231158180.16269>