[ANNOUNCE] libxshmfence 1.0
Matthieu Herrb
matthieu.herrb at laas.fr
Sun Nov 3 10:20:55 CET 2013
On Sat, Nov 02, 2013 at 12:39:40AM -0700, 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/
Ah, if the whole point of not beeing able to use pthreads is about
mixing 32 and 64 bits mode clients on the same X sever, OpenBSD is not
really affected since they choosed to not support 32 bits processes on
their 64 bits kernels. So I can move forward and implement xshmfence
for OpenBSD using your code below :)
(Well OpenBSD has some Linux compat code too, where pthread objects
will probably not be shareable between linux and native processes, and
this could be a problem, but I doubt that the linux compat code
actually allows to run a dri client anyways).
>
> 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.
>
> Off the top of my head (sorry for the int32_t * argument type):
>
> struct xshmfence {
> pthread_mutex_t lock;
> pthread_cond_t wakeup;
> int value;
> int waiting;
> };
>
> /**
> * xshmfence_trigger:
> * @f: An X fence
> *
> * Set @f to triggered, waking all waiters.
> *
> * Return value: 0 on success and -1 on error (in which case, errno
> * will be set as appropriate).
> **/
> int
> xshmfence_trigger(int32_t *v) {
> struct xshmfence *f = (struct xshmfence *) v;
>
> pthread_mutex_lock(&f->lock);
> if (f->value == 0) {
> f->value = 1;
> if (f->waiting) {
> f->waiting = 0;
> pthread_cond_broadcast(&f->wakeup);
> }
> }
> pthread_mutex_unlock(&f->lock);
> return 0;
> }
>
> /**
> * xshmfence_await:
> * @f: An X fence
> *
> * Wait for @f to be triggered. If @f is already triggered, this
> * function returns immediately.
> *
> * Return value: 0 on success and -1 on error (in which case, errno
> * will be set as appropriate).
> **/
> int
> xshmfence_await(int32_t *v) {
> struct xshmfence *f = (struct xshmfence *) v;
>
> pthread_mutex_lock(&f->lock);
> if (f->value == 0) {
> f->waiting = 1;
> pthread_cond_wait(&f->wakeup, &f->lock);
> }
> pthread_mutex_unlock(&f->lock);
> return 0;
> }
>
> /**
> * xshmfence_query:
> * @f: An X fence
> *
> * Return value: 1 if @f is triggered, else returns 0.
> **/
> int
> xshmfence_query(int32_t *v) {
> struct xshmfence *f = (struct xshmfence *) v;
> int value;
>
> pthread_mutex_lock(&v->lock);
> value = f->value;
> pthread_mutex_unlock(&v->lock);
> return value;
> }
>
> /**
> * xshmfence_reset:
> * @f: An X fence
> *
> * Reset @f to untriggered. If @f is already untriggered,
> * this function has no effect.
> **/
> void
> xshmfence_reset(int32_t *f) {
> struct xshmfence *f = (struct xshmfence *) v;
>
> pthread_mutex_lock(&f->lock);
> f->value = 0;
> pthread_mutex_unlock(&f->lock);
> }
>
> > Right now, xorg-server cannot build without xshmfence, and xshmfence cannot
> > build without Linux-only API's. There needs to be some way for Solaris,
> > BSD, MacOS and Cygwin to build without this, whether it's making xshmfence
> > optional for xorg-server or making xshmfence work with mutexes or other
> > portable API's.
>
> We can certainly disable DRI3 for platforms that don't have xshmfence
> available. I'm sorry I didn't do that when I added the DRI3 tests to the
> configure script.
>
> --
> keith.packard at intel.com
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
--
Matthieu Herrb
More information about the xorg-devel
mailing list