This is the mail archive of the cygwin-xfree mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: checkX problems


Lothar Brendel wrote:
> Ok, this can be cured by
> 
>    if (pthread_cond_timedwait (&cv_xopenOK, &mtx_xopenOK, &then) ==
> ETIMEDOUT) {
>      xopenOK = XSERV_TIMEDOUT; /* it's okay, we have the mutex */
>      xopenTrying = 0;  /* allow open_display() to give up */
> +      pthread_mutex_unlock(&mtx_xopenOK); /* allow for a last minute
> change */
>    }    /* else open_display() was successful */
>    pthread_detach(id);  /* leave open_display() on its own */

Not, that won't do it -- because now that you've unlocked the mutex, you
can't guarantee that the worker thread hasn't locked it again by the
time you try to destroy the mutex.  You can't move the
pthread_mutex_destroy call to the worker thread -- because what if there
never IS a successful return from the call to XOpenDisplay?  And finally
-- a little bit later in the main thread you are going to USE the value
of xopenOK to compute your return value -- but it's not an atomic
operation so you don't know if the worker thread is going to change
xopenOK's value in the middle of that operation.

AFAICT, the "cure" for all of these problems is worse than the disease
-- and the only *total* fix is for the main thread to always join() the
worker.  Which is precisely what we want to avoid.

There are a few *minor* tweaks that could improve things, but I'm
willing to go ahead with the current as a test release (as soon as my
ITP for libustr is approved; it's a new dependency for run2).

> But the problem is not so much destroying a locked mutex, but rather
> locking a destroyed mutex, right?

Well, frankly by the time that could happen I really don't care what the
worker thread does, so long as it doesn't crash the whole process. We've
already detached from it, and just want it to finish its call to
XOpenDisplay() and terminate.

> This happens in your race condition but also whenever ``delay'' is
> shorter than the time spent in a successful XOpenDisplay(). The failure
> doesn't really harm, but we can be less dirty by checking the result of
> pthread_mutex_unlock(), cf. the new patch.

No, I don't think we should unlock the mutex in the main thread, at
least until after we've computed the return value.  And once we DO
unlock the mutex, there just is NO WAY to guarantee that the worker
won't (successfully) lock the mutex, but not also have unlocked it, by
the time we try to call pthread_mutex_destroy -- except by waiting until
the worker thread exits (e.g. pthread_join()). Which we don't want to
do.  (If you try to relock the mutex in the main thread, you're right
back where we started...)

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]