pthreads, Xlib and me ...

Hi all,

well, another "i must be doing something wrong"
issue...

here is the quick sample program:

#include <unistd.h>
#include <pthread.h>
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/Xatom.h>

#include <GL/glx.h>
#include <GL/gl.h>

void * blockingThread (void *opaque)
{
	Display *dpy (XOpenDisplay (NULL));
	if (dpy != NULL)
	{
		if (glXQueryExtension(dpy, NULL, NULL))
		{
			int majorVersionNumber, minorVersionNumber;
			glXQueryVersion (dpy, &majorVersionNumber,
&minorVersionNumber);
		}
	}
	return NULL;
}

int main ()
{
	XInitThreads ();
	pthread_t blockingThreadId;
	pthread_create (&blockingThreadId, NULL,
blockingThread, NULL);
	sleep (10);

	return 0;
}

Here is a rough build description

gcc -I/usr/X11R6/include main.cc -L/usr/X11R6/lib -lGL -lX11
-lstdc++
-lm -lpthread

generates:

/usr/X11R6/lib/libX11.so: warning: warning: reference to
compatibility
socket(); include <sys/socket.h> for correct
reference
/usr/X11R6/lib/libX11.so: warning: warning: reference to
compatibility
__stat13(); include <sys/stat.h> to generate correct
reference
/usr/X11R6/lib/libX11.so: warning: warning: reference to
compatibility
__fstat13(); include <sys/stat.h> to generate correct
reference

and at runtime:

a.out: Error detected by libpthread: Unlocking unlocked
mutex.
Detected by file
"/usr/src/lib/libpthread/pthread_mutex.c", line
369,
function "pthread_mutex_unlock".
See pthread(3) for information.

I have noticed that I am not closing the X display in this
sample
code...  but don't think this is the cause of the problem
(in the
actual app there is a correspording XCloseDisplay call) - I
shall try
this sample code with XCloseDisplay as well... - not near my
NetBSD
box, as currently I rarely get a chance to play with it...

Can anyone out there reproduce the "unlocking unlocked
mutex" error
(in my case, I can get rid of it if I take out
"XInitThreads" but in
practice (my app) the "XInitThreads" needs to
remain) ?

On Fri, Mar 23, 2007 at 09:34:09AM +1000, leon zadorin
wrote:
> Hi all,
> 
> well, another "i must be doing something
wrong" issue...
> 
> here is the quick sample program:
> 
> #include <unistd.h>
> #include <pthread.h>
> #include <X11/Xlib.h>
> #include <X11/Xutil.h>
> #include <X11/Xatom.h>
> 
> #include <GL/glx.h>
> #include <GL/gl.h>
> 
> void * blockingThread (void *opaque)
> {
> 	Display *dpy (XOpenDisplay (NULL));
> 	if (dpy != NULL)
> 	{
> 		if (glXQueryExtension(dpy, NULL, NULL))
> 		{
> 			int majorVersionNumber, minorVersionNumber;
> 			glXQueryVersion (dpy, &majorVersionNumber, 
> 			&minorVersionNumber);
> 		}
> 	}
> 	return NULL;
> }
> 
> int main ()
> {
> 	XInitThreads ();
> 	pthread_t blockingThreadId;
> 	pthread_create (&blockingThreadId, NULL,
blockingThread, NULL);
> 	sleep (10);
> 
> 	return 0;
> }
> 
> Here is a rough build description
> 
> gcc -I/usr/X11R6/include main.cc -L/usr/X11R6/lib -lGL
-lX11 -lstdc++
> -lm -lpthread
> 
> generates:
> 
> /usr/X11R6/lib/libX11.so: warning: warning: reference
to compatibility
> socket(); include <sys/socket.h> for correct
reference
> /usr/X11R6/lib/libX11.so: warning: warning: reference
to compatibility
> __stat13(); include <sys/stat.h> to generate
correct reference
> /usr/X11R6/lib/libX11.so: warning: warning: reference
to compatibility
> __fstat13(); include <sys/stat.h> to generate
correct reference

Ok, those indicate that your libX11.so may be old or that it
explicitly 
referenced old symbols.

> and at runtime:
> 
> a.out: Error detected by libpthread: Unlocking unlocked
mutex.
> Detected by file
"/usr/src/lib/libpthread/pthread_mutex.c", line
369,
> function "pthread_mutex_unlock".
> See pthread(3) for information.
> 
> I have noticed that I am not closing the X display in
this sample
> code...  but don't think this is the cause of the
problem (in the
> actual app there is a correspording XCloseDisplay call)
- I shall try
> this sample code with XCloseDisplay as well... - not
near my NetBSD
> box, as currently I rarely get a chance to play with
it...
> 
> Can anyone out there reproduce the "unlocking
unlocked mutex" error
> (in my case, I can get rid of it if I take out
"XInitThreads" but in
> practice (my app) the "XInitThreads" needs to
remain) ?

I know very little about X, but aren't you supposed to be
calling 
XLockDisplay at points?

Take care,

Bill

On 3/28/07, Bill Stouder-Studenmund <wrstudennetbsd.org> wrote:
> I know very little about X, but aren't you supposed to
be calling
> XLockDisplay at points?

mmm... I was under the impression that it would only be
needed if a
given pointer to  Display (as obtained from XOpenDisplay)
was accessed
from multiple threads... now, since (in my sample) the
XOpenDisplay
returns a pointer which is only being accessed from the very
thread
that called XOpenDisplay, then AFAIK one does not need to
call
XLockDisplay...

I mean the very signature of XLockDisplay takes a pointer to
Display
which is to be locked: "The XLockDisplay() function
locks out all
other threads from using the specified display"...

In other words, my understanding is that if different
threads use
XOpenDisplay and do not "cross-touch" the Display
pointers (returned
by their respective XOpenDisplay calls) then there is no
need to call
XLockDisplay...

In my sample, there was only 1 thread which did both:
called
XOpenDisplay and accessed it (via  glXQueryExtension and
glXQueryVersion)...

But I would welcome more info or arguments on this subject

On 3/28/07, leon zadorin <leonleon77gmail.com> wrote:
> On 3/28/07, Bill Stouder-Studenmund <wrstudennetbsd.org> wrote:
> > I know very little about X, but aren't you
supposed to be calling
> > XLockDisplay at points?

by the way - are you able to compile and run the
aforementioned code
on your system?

On Wed, Mar 28, 2007 at 03:38:01PM +1000, leon zadorin
wrote:
> On 3/28/07, Bill Stouder-Studenmund <wrstudennetbsd.org> wrote:
> >I know very little about X, but aren't you supposed
to be calling
> >XLockDisplay at points?
> 
> mmm... I was under the impression that it would only be
needed if a
> given pointer to  Display (as obtained from
XOpenDisplay) was accessed
> from multiple threads... now, since (in my sample) the
XOpenDisplay
> returns a pointer which is only being accessed from the
very thread
> that called XOpenDisplay, then AFAIK one does not need
to call
> XLockDisplay...

I don't think so. You explicitly told X that you're in a
multi-threaded 
environment, and for X that means locking. If an X library
call expects 
something to be locked, you need to have it locked before
making the call.

> I mean the very signature of XLockDisplay takes a
pointer to Display
> which is to be locked: "The XLockDisplay()
function locks out all
> other threads from using the specified
display"...
> 
> In other words, my understanding is that if different
threads use
> XOpenDisplay and do not "cross-touch" the
Display pointers (returned
> by their respective XOpenDisplay calls) then there is
no need to call
> XLockDisplay...

While you are right that there will be no other thread you
need to lock 
out from accessing the display, that doesn't mean you can
ignore the 
locking that the library expects. The error you're getting
is "Unlocking 
unlocked mutex." That means the library expected
something locked and it 
isn't getting one.

> In my sample, there was only 1 thread which did both:
called
> XOpenDisplay and accessed it (via  glXQueryExtension
and
> glXQueryVersion)...
> 
> But I would welcome more info or arguments on this
subject 

Try the locking.

Oh, I haven't had a chance to test this program on macppc.

Take care,

Bill

On 3/30/07, Bill Stouder-Studenmund <wrstudennetbsd.org> wrote:

> > from multiple threads... now, since (in my sample)
the XOpenDisplay
> > returns a pointer which is only being accessed
from the very thread
> > that called XOpenDisplay, then AFAIK one does not
need to call
> > XLockDisplay...
>
> I don't think so. You explicitly told X that you're in
a multi-threaded
> environment, and for X that means locking. If an X
library call expects
> something to be locked, you need to have it locked
before making the call.

I am not sure that I agree... What I think I have explicitly
told X is
that I will be using XLockDisplay/XUnlockDisplay at SOME
points in my
code to prevent other threads from accessing the Display
structure...
it does not mean (AFAIK) that I am then obliged to lock
EVERY point of
access of the Display structure (e.g. when no other thread
touches the
display). I have not seen any doco which would state 
something
similar to "if you plan to call XLockDisplay at some
point, then you
must call XInitThreads first and then you must call
XLockDisplay at
every point/time you access Display retured by XOpenDisplay
- even if
no other threads are going to use the display".
Moreover, I haven't
seen any doco which would state that "you must have
Display locked
before calling a given Xxxx function if you called
XInitThreads
earlier on", nor have I seen any doco which would say
"if in
multithreaded environment - you must lock Display at all
times, even
if no other thread is going to access it"... but then
again I might be
missing something 

>From a higher level of understanding, what I think the
behaviour of
XLockDisplay/XUnlockDisplay to be is that *inside* XLib,
every call
that touches a given Display structure calls lock/unlock (on
XLib's
internal mutex initialised with XInitThreads which may or
may not be
allocted on 1:1 basis with a given Display structure) around
its code
(so it  does its own locking for anything it will unlock
later) - this
automatically locks out other (e.g. application's) threads
that might
be trying to touch the same Display. This offers a unique
synchronisiation capability that cannot be implemented by
Xlib clients
alone - because there is no way for the client to say where
the
internal Xlib's thread of execution is... and the best way
(IMHO) to
implement it would be the aforementioned description... But
then again
- I am rather ignorant... I think I might ask this question
on the
Xlib's developers forum 

> While you are right that there will be no other thread
you need to lock
> out from accessing the display, that doesn't mean you
can ignore the
> locking that the library expects. The error you're
getting is "Unlocking

I dont think that the library actually expects the locking
you
describe... in that I think the library would do its own
locking on
the section of the code which it expects to unlock later...

> Try the locking.

OK, ok ... I have - no difference at all - still the same
problem (see
earlier posts for log outputs, etc), here is the updated
code...

#include <unistd.h>
#include <pthread.h>
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/Xatom.h>

#include <GL/glx.h>
#include <GL/gl.h>

void * blockingThread (void *opaque)
{
       Display *dpy (XOpenDisplay (NULL));
       if (dpy != NULL)
       {
               XLockDisplay (dpy);
               if (glXQueryExtension(dpy, NULL, NULL))
               {
                       int majorVersionNumber,
minorVersionNumber;
                       glXQueryVersion (dpy,
&majorVersionNumber,
&minorVersionNumber);
               }
               XUnlockDisplay (dpy);
       }
       return NULL;
}

int main ()
{
       if (!XInitThreads ())
              return -1;
       pthread_t blockingThreadId;
       pthread_create (&blockingThreadId, NULL,
blockingThread, NULL);
       sleep (10);

       return 0;
}

> Oh, I haven't had a chance to test this program on
macppc.

On 3/30/07, leon zadorin <leonleon77gmail.com> wrote:
> be trying to touch the same Display. This offers a
unique
> synchronisiation capability that cannot be implemented
by Xlib clients
> alone - because there is no way for the client to say
where the
> internal Xlib's thread of execution is... and the best
way (IMHO) to

just a minor clarification - when I typed "internal
Xlib's thread of
execution"  I did not mean to imply that Xlib starts
its own internal
threads, but rather that in multithreaded app, there is a
thread which
runs Xlib/Xevents loop (e.g. the thread on which
"main" is running)
and there are other threads which do not know wher the
thread which
runs XLib happens to be: inside some XLib function which
alters
Display or not, so the fine-grained locking cannot be
achieved simply
by putting an "application-initilased" mutex locks
around the "main"
and other threads... which would appear to be a reason for
the whole
XLockDisplay feature (for XLib do its own lock/unlock around
sections
of the code which alter Display)... that is all - hmmm this
English
thing is rather hard