[sent to ian only by accident; resending to the list]
On Sun, Jan 18, 2009 at 12:17:28PM +0000, Ian Lynagh wrote:
> In fact, looking at pthread.h on Linux:
>
> #ifdef __USE_UNIX98
> ,
> PTHREAD_MUTEX_NORMAL = PTHREAD_MUTEX_TIMED_NP,
> PTHREAD_MUTEX_RECURSIVE = PTHREAD_MUTEX_RECURSIVE_NP,
> PTHREAD_MUTEX_ERRORCHECK = PTHREAD_MUTEX_ERRORCHECK_NP,
> PTHREAD_MUTEX_DEFAULT = PTHREAD_MUTEX_NORMAL
> #endif
>
> so maybe we can just use PTHREAD_MUTEX_ERRORCHECK everywhere.
Yes. That should make ASSERT_LOCK_HELD work without blocking the
calling thread.
And forget about my previous mumbling that it's impossible to
implement ASSERT_LOCK_HELD -- i wrote that i didn't have breakfast,
did i ;-)
> > pthread_mutexattr_init(&a);
> > pthread_mutexattr_settype(&a, PTHREAD_MUTEX_NORMAL);
> > pthread_mutex_init(&m, &a);
> > pthread_mutex_lock(&m);
> > pthread_mutex_lock(&m); /* blocking here */
> >
> > IMHO there's no portable and clean way to check wether you already
> > have a lock on a mutex or not (but I didn't yet have breakfast, so
> > this statement may be wrong). Regardless of wether you're trying
> > pthread_mutex_lock with a mutex type of PTHREAD_MUTEX_ERRORCHECK
> > or wether you're trying pthread_mutex_trylock (which never blocks),
> > you get the wrong result, at least on OpenBSD.
>
> Really? FWIW, my Linux manpage says:
> If the mutex is of the ??????error checking?????? kind, pthread_mutex_lock
> returns immediately with the error code EDEADLK.
>
> What "wrong result" do you get with PTHREAD_MUTEX_ERRORCHECK and
> pthread_mutex_lock?
With ERRORCHECK I get an EDEADLK on the second pthread_mutex_lock().
> > Even on Linux, ASSERT_LOCK_HELD may have undesired effects: if you
> > call it on an unlocked mutex, you will get a positive result and
> > at the same time have locked the mutex.
>
> And the assert (that the result was EDEADLK) will fail, so the program
> terminates.
Ah, right, I was confused. Stupid me.
Ciao,
Kili
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
