> Date: Wed, 06 Nov 2013 13:09:26 -0800 > From: Alan Coopersmith <[email protected]> > > On 11/ 2/13 12:39 AM, Keith Packard wrote: > > Alan Coopersmith <[email protected]> writes: > > > >> What about platforms which don't have <linux/futex.h> ? > > > > I looked into alternate synchronization mechanisms; I couldn't figure > > out how to use standard pthread APIs to provide the desired semantics. > > > > Here's the detailed write up I did that describes the SyncFence > > semantics and how those map directly to Linux Futexes: > > > > http://keithp.com/blogs/Shared_Memory_Fences/ > > > > If you can figure out how to build this with pthread mutexes and/or > > semaphores, then we could create a version of xshmfence that worked > > using regular pthread functions. As I understand it, pthread > > synchronization primitives are supposed to work across processes that > > share memory, even if they use different virtual addresses to reference > > the same object. > > I've checked with the Solaris kernel & libc folks, and they confirm there's > no problem using the POSIX API's on Solaris - ours are correctly implemented > using uint{16,32,64}_t types so they are the same on 32-bit & 64-bit ABI's, > and they're documented & supported as being compatible across the two. > > Specifically they said: > > "On Solaris, mutexes in shared memory, shared among 32-bit and 64-bit > processes, work correctly. All of the other locking thingies work > correctly too: > > condvars > rwlocks > semaphores > barriers > message queues" > > And one of our old timers pointed out: > > "Note that this is exactly the same problem that Solaris (SunOS first) > solved with the winlock driver. > > > https://hg.java.net/hg/solaris~on-src/file/tip/usr/src/uts/common/io/winlockio.c#l27 > > This was an real factor in the excellent performance of sundgadoom 8-)." > > (Honestly, I vaguely knew we had winlockio, but not what it was for. Our Xorg > doesn't use it, only our old Xsun implementation with its SUN-DGA > extension.) > > So between this & the comments from the BSD guys, it seems like POSIX API's > should be the default implementation for all platforms except Linux multi-lib > platforms with incompatible implementations, where you have to use futexes > instead to work around platform bugs.
As I said, currently OpenBSD doesn't implement the process-shared stuff, but I'm already looking into implementing the necessary functionality. So I'd say that the POSIX API's are indeed the way to go. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
