[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pthread fast mutexes

From: Mikael Djurfeldt
Subject: Re: pthread fast mutexes
Date: Mon, 23 Feb 2004 17:05:16 -0500
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Kevin Ryde <address@hidden> writes:

> In the current cvs on my i386 debian,
>       (unlock-mutex (make-mutex))
> gives a seg fault.
> I'm guessing it's because make-mutex uses a pthread fast mutex, and
> that style means no error checking by the unlock.
> Maybe the scheme level functions will need to use the "normal" mutexes
> so the above can throw an exception.  Or is there some other theory on
> this?

The "theory" is this:

The idea of the current thread interface design is to be able to "plug
in" a thread library.  It's therefore good if we keep the demands on
the thread library to a minimum.  Not all thread libraries supports
detection of this kind of error.  Therefore I opted for leaving it
undefined what happens if you try to unlock an unlocked mutex.

Here's an excerpt of the docs for pthread_mutex_unlock:

  pthread_mutex_unlock unlocks the given mutex. The mutex is assumed to
  be locked and owned by the calling thread on entrance to
  pthread_mutex_unlock.  If the mutex is of the ``fast'' kind,
  pthread_mutex_unlock always returns it to the unlocked state.

Therefore, fast mutexes are consistent with the requirements of the
interface, and they are, well, fast...  The call above doesn't
generate a segfault on my system.

BUT, obviously, if these docs don't hold for the fast mutexes on other
systems, then we can't use them on those systems.  How is
pthread_mutex_unlock for a fast mutyex documented on your system?

Also, my design choices above could be discussed.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]