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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
