[ANNOUNCE] libxshmfence 1.0

[Mark Kettenis]

> Date: Wed, 06 Nov 2013 13:09:26 -0800
> From: Alan Coopersmith <alan.coopersmith at oracle.com>
> 
> On 11/ 2/13 12:39 AM, Keith Packard wrote:
> > Alan Coopersmith <alan.coopersmith at oracle.com> 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.