pthread fast mutexes

pthread fast mutexes

[Kevin Ryde]

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?


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: pthread fast mutexes

[Mikael Djurfeldt]

Kevin Ryde <user42@zip.com.au> 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.

M


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: pthread fast mutexes

[Mikael Djurfeldt]

Mikael Djurfeldt <mdj@mit.edu> writes:

> Therefore, fast mutexes are consistent with the requirements of the
> interface, and they are, well, fast...

Actually, there's more to it than that:

Guile has two kinds of mutexes:

1. The ones you get with (make-mutex)

   These are efficient.  They are also used internally and in the
   application C API.  Therefore, any speed penalty on these will have
   a global effect on all programs in a Guile with threading
   activated.  I actually did a benchmark between fast and normal
   mutexes and there is a significant difference in run-time for
   non-threaded programs in such a Guile.

2. The ones you get with (make-fair-mutex)

   These are fair, recursive and error checking.
   Simply put: These are the mutexes with all bells and whistles.

   Try (unlock-mutex (make-fair-mutex))

Given that we really need very efficient mutexes in Guile internals,
and that one probably would like to be able to use these from the
Scheme level if we also provide a "safe" alternative, I really
wouldn't like to abstain from the "fast" mutexes of pthreads.

If people think it is a really bad idea not to have better error
checking on the mutexes you get from (make-mutex), one possibility is
to make the following name substitutions:

make-mutex      --> make-fast-mutex
make-fair-mutex --> make-mutex

M


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: pthread fast mutexes

[Kevin Ryde]

Mikael Djurfeldt <mdj@mit.edu> writes:
>
> make-mutex      --> make-fast-mutex
> make-fair-mutex --> make-mutex

That might be prudent if in the past make-mutex had been safe to
various abuses.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: pthread fast mutexes

[Mikael Djurfeldt]

Kevin Ryde <user42@zip.com.au> writes:

> Mikael Djurfeldt <mdj@mit.edu> writes:
>>
>> make-mutex      --> make-fast-mutex
>> make-fair-mutex --> make-mutex
>
> That might be prudent if in the past make-mutex had been safe to
> various abuses.

Well, but the past mutexes didn't report an error either.  I've not
taken away any semantics.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: pthread fast mutexes

[Kevin Ryde]

Mikael Djurfeldt <djurfeldt@nada.kth.se> writes:
>
> Well, but the past mutexes didn't report an error either.  I've not
> taken away any semantics.

Ah yes.  Ok, below is some words for the manual to try to clarify the
situation.  In particular I take it the current words about mutexes
being recursive applies only to fair mutexes.

(This is also what I threatened about collecting up of all mutex stuff
into one section, instead of spread through three places.)



Mutexes
=======

 - Scheme Procedure: make-mutex
 - Scheme Procedure: make-fair-mutex
     Create a new mutex object.

     A standard mutex (`make-mutex') is fast, but its features are
     minimal.  Recursive locking (multiple lock calls) is not permitted,
     and an unlock can be done only when already locked, and only by the
     owning thread.  When multiple threads are blocked waiting to
     acquire the mutex, it's unspecified which will get it next.

     A fair mutex (`make-fair-mutex') on the other hand has more
     features and error checking.  Recursive locking is allowed, a given
     thread can make multiple lock calls and the mutex is released when
     a balancing number of unlocks are done.  Other threads blocked
     waiting to acquire the mutex form a queue and the one waiting
     longest will be the next to acquire it.

     Note that in both cases there is no protection against a "deadly
     embrace".  For instance currently an endless wait will occur if one
     thread has locked mutex A and is waiting on mutex B, but another
     thread owns B and is waiting on A.  Acquiring requisite mutexes in
     a fixed order (like always A before B) in all threads is one way to
     avoid such problems.

 - Scheme Procedure: lock-mutex mutex
     Lock MUTEX.  If the mutex is already locked by another thread then
     the calling thread is blocked and `lock-mutex' only returns when
     the mutex is acquired and locked.

     For standard mutexes (`make-mutex'), a thread which has locked
     MUTEX must not call `lock-mutex' on it a further time.  Behaviour
     is unspecified if this is done.

     For a fair mutex (`make-fair-mutex'), a thread may call
     `lock-mutex' to lock MUTEX again, this will then require a further
     balancing `unlock-mutex' to release.

     When a system async is activated for a thread blocked in a call to
     `lock-mutex', the waiting is interrupted and the async is
     executed.  When the async returns, the waiting is resumed.

 - Scheme Procedure: try-mutex mutex
     Try to lock MUTEX as per `lock-mutex', but without waiting.  If
     MUTEX can be acquired immediately, this is done and the return is
     `#t'.  If MUTEX is owned by some other thread then nothing is done
     and the return is `#f'.

 - Scheme Procedure: unlock-mutex mutex
     Unlock MUTEX.

     For a standard mutex (`make-mutex'), behaviour is unspecified if
     the calling thread has not locked MUTEX.

     For a fair mutex (`make-fair-mutex'), an error is thrown if the
     calling thread does not own MUTEX.


 - macro: with-mutex mutex [body...]
     Lock MUTEX, evaluate BODY, and then unlock MUTEX.  These
     sub-operations form the branches of a `dynamic-wind', so MUTEX is
     unlocked if an error or new continuation exits BODY, and is
     re-locked if BODY is re-entered by a captured continuation.

 - macro: monitor body...
     Evaluate BODY, with a mutex locked so only one thread can execute
     that code at any one time.  The return value is the return from
     the last form in BODY.

     Each `monitor' form has its own private mutex and the locking is
     done as per `with-mutex' above.  A standard mutex (`make-mutex')
     is used, which means BODY must not recursively re-enter its
     `monitor' form.

     The term "monitor" comes from operating system theory, where it
     means a particular bit of code managing access to some resource and
     which only ever executes on behalf of one process at any one time.


   For C code, the standard mutexes described above can be used with the
following C datatype and functions.

 - C Data Type: scm_t_mutex
     A mutex, to be used with `scm_mutex_init', etc.

 - C Function: void scm_mutex_init (scm_t_mutex *m)
     Initialize the mutex structure pointed to by M.

 - C Function: void scm_mutex_destroy (scm_t_mutex *m)
     Deallocate all resources associated with M.

 - C Function: void scm_mutex_lock (scm_t_mutex *m)
     Lock the mutex M.  When it is already locked by a different
     thread, wait until it becomes available.  Locking a mutex that is
     already locked by the current threads is not allowd and results in
     undefined behavior.  The mutexes are not guaranteed to be fair.
     That is, a thread that attempts a lock after yourself might be
     granted it before you.

 - C Function: int scm_mutex_trylock (scm_t_mutex *m)
     Lock M as per `scm_mutex_lock' but don't wait.  Return non-zero
     when the mutex has been locked, or return zero if it is already
     locked by some other thread.

 - C Function: void scm_mutex_unlock (scm_t_mutex *m)
     Unlock the mutex M.  The mutex must have been locked by the
     current thread, else the behavior is undefined.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: pthread fast mutexes

[Marius Vollmer]

Mikael Djurfeldt <mdj@mit.edu> writes:

> If people think it is a really bad idea not to have better error
> checking on the mutexes you get from (make-mutex), one possibility is
> to make the following name substitutions:
>
> make-mutex      --> make-fast-mutex
> make-fair-mutex --> make-mutex

That's a good idea, I think.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: pthread fast mutexes

[Kevin Ryde]

Mikael Djurfeldt <mdj@mit.edu> writes:
>
>   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.

I suppose it's unspecified what happens if you don't satisfy those
requirements.  I seem to get a segv.  (glibc 2.3.2, kernel 2.2.15)

Maybe the scheme mutex type will have to make a note of its state or
something, to be sure of obeying the rules.

> 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?

I'm not sure where it's supposed to hide on debian.  I'm looking at
the linuxthreads/man/*.man pages in the glibc sources.  It says what
you said.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: pthread fast mutexes

[Mikael Djurfeldt]

Kevin Ryde <user42@zip.com.au> writes:

> Mikael Djurfeldt <mdj@mit.edu> writes:
>>
>>   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.
>
> I suppose it's unspecified what happens if you don't satisfy those
> requirements.  I seem to get a segv.  (glibc 2.3.2, kernel 2.2.15)

I think you're right.  I've misinterpreted the docs.  I read 'always
returns it' without the qualifier 'is assumed to be locked'.

> Maybe the scheme mutex type will have to make a note of its state or
> something, to be sure of obeying the rules.

Since that is a little tricky (would probably need an extra mutex or
condition variable to implement it), it might be better to simply use
error checking mutexes.

>> 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?
>
> I'm not sure where it's supposed to hide on debian.  I'm looking at
> the linuxthreads/man/*.man pages in the glibc sources.  It says what
> you said.

That's the place to look.

(I'll try to verify it in the pthread library sources also.)

M


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: pthread fast mutexes

[Marius Vollmer]

Mikael Djurfeldt <djurfeldt@nada.kth.se> writes:

> Since that is a little tricky (would probably need an extra mutex or
> condition variable to implement it), it might be better to simply use
> error checking mutexes.

Yep.  We shouldn't allow the program to crash by unlocking a unlocked
mutex.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel