Recursive mutexes?

Recursive mutexes?

[Marius Vollmer]

Our current coop mutexes are not 'recursive'.  This means that a
thread blocks when it tries to lock a mutex that it already has
locked.

I think we should make our mutexes be recursive by default.  Expecting
to block when locking a mutex that is already lcoked by one self is
not very useful, since no one can unlock that mutex (excepts asyncs).

The only good argument against recursive mutexes that I can think of
is a tiny performance gain since you don't need to do some checking.

SRFI-18 specifies non-recursive mutexes and allows non-owning threads
to unlock a mutex.  Such uses of a mutex are, in my view, a mockery of
condition variables should be avoided.

If non-recursive mutexes turn out to be important, we can provide them
as well, as an option.

Ok?

-- 
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: Recursive mutexes?

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <mvo@zagadka.ping.de> writes:

    Marius> Our current coop mutexes are not 'recursive'.  This means that a
    Marius> thread blocks when it tries to lock a mutex that it already has
    Marius> locked.

    Marius> I think we should make our mutexes be recursive by default.  Expecting
    Marius> to block when locking a mutex that is already lcoked by one self is
    Marius> not very useful, since no one can unlock that mutex (excepts asyncs).

True, but a situation like this (the same thread trying to relock the
same mutex) can alert you to a programming error.  A dramatic problem
(the program hanging) is often more useful than the error being hidden.

    Marius> The only good argument against recursive mutexes that I can think of
    Marius> is a tiny performance gain since you don't need to do some checking.

IIRC, it's easy to implement a recursive mutex if you already have a
non-recursive one, but the reverse is not so easy.

    Marius> SRFI-18 specifies non-recursive mutexes and allows non-owning threads
    Marius> to unlock a mutex.

On first hearing, this sounds like it could be a useful feature.

    Marius> Such uses of a mutex are, in my view, a mockery of
    Marius> condition variables should be avoided.

I think you'll have to rephrase that! :-)

    Marius> If non-recursive mutexes turn out to be important, we can provide them
    Marius> as well, as an option.

I'm pretty sure they are important (enough), so I suggest that we
provide both.  What would be quite nice (and I think is possible)
would be to implement non-recursive mutexes in a
thread-implementation-specific way, and then recursive mutexes in a
generic way based on whatever non-recursive mutex is currently
configured.

        Neil



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

Re: Recursive mutexes?

[Marius Vollmer]

Neil Jerram <neil@ossau.uklinux.net> writes:

> >>>>> "Marius" == Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
>     Marius> I think we should make our mutexes be recursive by
>     Marius> default.  Expecting to block when locking a mutex that
>     Marius> is already lcoked by one self is not very useful, since
>     Marius> no one can unlock that mutex (excepts asyncs).
> 
> True, but a situation like this (the same thread trying to relock the
> same mutex) can alert you to a programming error.  A dramatic problem
> (the program hanging) is often more useful than the error being hidden.

Yes.  But shouldn't a non-recursive mutex signal an error in this case?

> IIRC, it's easy to implement a recursive mutex if you already have a
> non-recursive one, but the reverse is not so easy.

Yes, true.  But what should be the default type?  We should offer
recursive mutexes in any case, and I think they should be the default.

What about having only one type of mutex but different kind of locking
functions?  One for recursive locks and one for non-recursive error
checking ones.  That seems mighty clean to me.

>     Marius> Such uses of a mutex are, in my view, a mockery of
>     Marius> condition variables should be avoided.
> 
> I think you'll have to rephrase that! :-)

Err, there's a "and" missing: "and should be avoided."

>     Marius> If non-recursive mutexes turn out to be important, we
>     Marius> can provide them as well, as an option.
> 
> I'm pretty sure they are important (enough), so I suggest that we
> provide both.  What would be quite nice (and I think is possible)
> would be to implement non-recursive mutexes in a
> thread-implementation-specific way, and then recursive mutexes in a
> generic way based on whatever non-recursive mutex is currently
> configured.

Given what I have planned for our threads, we would need to implement
our own mutexes anyway (using pthread mutexes, for example).  I would
like to extent 'select' (with a new name) so that it can wait on IO
and mutexes and condition variables and other stuff at the same time.

That is, you would be able to wait for two condition variables, say,
and wake up when one of them is signalled.

This is something that you can build on top of the primitives, but I
think we should offer rich tools that do a lot of useful things out of
the box.

-- 
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: Recursive mutexes?

[Thomas Bushnell, BSG]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Neil Jerram <neil@ossau.uklinux.net> writes:
> 
> > >>>>> "Marius" == Marius Vollmer <mvo@zagadka.ping.de> writes:
> > 
> >     Marius> I think we should make our mutexes be recursive by
> >     Marius> default.  Expecting to block when locking a mutex that
> >     Marius> is already lcoked by one self is not very useful, since
> >     Marius> no one can unlock that mutex (excepts asyncs).
> > 
> > True, but a situation like this (the same thread trying to relock the
> > same mutex) can alert you to a programming error.  A dramatic problem
> > (the program hanging) is often more useful than the error being hidden.
> 
> Yes.  But shouldn't a non-recursive mutex signal an error in this case?

No.  A non-recursive mutex should block in a case like this.

It's not an error to try and lock a mutex which is already locked,
even if it's already locked by your own thread.

Please, there are already standard semantics for these objects, in use
across a jillion languages.  Changing them is a little like deciding
that you are going to implement integer addition as NIM addition,
normal conventions be damned.

> Yes, true.  But what should be the default type?  We should offer
> recursive mutexes in any case, and I think they should be the default.

Why?  Recursive mutexes are much more heavyweight in general, and are
usually totally unnecessary.

> What about having only one type of mutex but different kind of locking
> functions?  One for recursive locks and one for non-recursive error
> checking ones.  That seems mighty clean to me.

The only implementation of such a thing which I've thought of ends up
imposing the extra cost of a recursive mutex on all users.



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

Re: Recursive mutexes?

[Marius Vollmer]

tb@becket.net (Thomas Bushnell, BSG) writes:

[ locking a non-recursive mutex when it is already locked by the same
  thread.]

> > Yes.  But shouldn't a non-recursive mutex signal an error in this case?
> 
> No.  A non-recursive mutex should block in a case like this.

Why?  Because it is cheaper, or because it is the Right Thing?

> It's not an error to try and lock a mutex which is already locked,
> even if it's already locked by your own thread.

What use does this have?  Are there well-known patterns were you rely
on this?

> Please, there are already standard semantics for these objects, in
> use across a jillion languages.

Are there?  Do they really all agree on whether mutexes are recursive
or not, and whether you are allowed to unlock a mutex from a
non-owning thread, and on what should happen when you lock a
non-recursive mutex that you already own?  I don't have that
impression, from my admittedly little experience.  Can you point me to
a description of these standard semantics?  You sound like they are
obvious, but they are not to me, yet.

> Changing them is a little like deciding that you are going to
> implement integer addition as NIM addition, normal conventions be
> damned.

It's more like deciding to offer bignums in addition, because they are
nicer than modulo 2^x arithmetic.  Most people don't want module 2^x
arithmetic when they use "int" in C, they just are careful to stay
within the region where C integer addition models real integer
addition.  What was the reason again to go to 64 bit?  That the UNIX
clock will not roll over? ;-)

Right now, I suspect that the reason d'etre for non-recursive mutexes
is that they are faster.  Nothing more.  I would like to hear other
reasons since the cost of recursive mutexes is not too high, in my
view.

> > Yes, true.  But what should be the default type?  We should offer
> > recursive mutexes in any case, and I think they should be the default.
> 
> Why?  Recursive mutexes are much more heavyweight in general, and are
> usually totally unnecessary.

"Much more" is a subjective measure.  As I see it, "much more" amounts
to two additional fields in the data structure and one comparison
during lock and unlock each.  This is not much more for the context
that our mutexes operate in.

> > What about having only one type of mutex but different kind of locking
> > functions?  One for recursive locks and one for non-recursive error
> > checking ones.  That seems mighty clean to me.
> 
> The only implementation of such a thing which I've thought of ends up
> imposing the extra cost of a recursive mutex on all users.

Yes.  I am not trying to lower the cost here but to give non-recursive
mutexes to people who want them.

-- 
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: Recursive mutexes?

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <mvo@zagadka.ping.de> writes:

    Marius> Neil Jerram <neil@ossau.uklinux.net> writes:
    >> 
    >> True, but a situation like this (the same thread trying to relock the
    >> same mutex) can alert you to a programming error.  A dramatic problem
    >> (the program hanging) is often more useful than the error being hidden.

    Marius> Yes.  But shouldn't a non-recursive mutex signal an error in this case?

Traditionally no - it just hangs.  But I can't think of a reason why
this behaviour is good, and why it wouldn't be better to signal an
error.

I'm not sure Thomas's point about traditional semantics is valid,
since mutexes are normally provided by relatively low-level interfaces
(e.g. POSIX, Win32) that don't support exceptions.

    Marius> What about having only one type of mutex but different kind of locking
    Marius> functions?  One for recursive locks and one for non-recursive error
    Marius> checking ones.  That seems mighty clean to me.

Sounds nice to me too.

    Marius> Such uses of a mutex are, in my view, a mockery of
    Marius> condition variables should be avoided.
    >> 
    >> I think you'll have to rephrase that! :-)

    Marius> Err, there's a "and" missing: "and should be avoided."

Some uses of this would be a mockery of condition variables, I agree.
But there are other possible uses, e.g. a program cleaning up before
exiting, that needs to do its thing even when other program threads
may have hung.  So, if the implementation is not too hard, I think we
should have this interface.

    Marius> Given what I have planned for our threads, we would need to implement
    Marius> our own mutexes anyway (using pthread mutexes, for example).  I would
    Marius> like to extent 'select' (with a new name) so that it can wait on IO
    Marius> and mutexes and condition variables and other stuff at the same time.

Win32 has this: `WaitForMultipleObjects'.  Can it be done in a POSIX
system without polling?

    Marius> This is something that you can build on top of the primitives, but I
    Marius> think we should offer rich tools that do a lot of useful things out of
    Marius> the box.

Totally.

        Neil



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

Re: Recursive mutexes?

[Rob Browning]

Neil Jerram <neil@ossau.uklinux.net> writes:

> Win32 has this: `WaitForMultipleObjects'.  Can it be done in a POSIX
> system without polling?

Yes, I think so -- if you let a helper thread (or threads) handle
watching for whatever events the user threads are interested in.  The
watcher thread(s) then signals a condition variable (or semaphore or
whatever) that the user thread is blocked on whenever an event the
user thread is interested in arrives.

Whether you have one watcher thread or many, and whether you break
them up by type or not (say one for POSIX IO, one for GTK, one for
KDE), depends on implementation details.

This presumes that the events that the helper thread(s) will be
watching can be waited on without polling, but even if polling is
required, it can be limited to the relevant watcher thread(s).

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: Recursive mutexes?

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Our current coop mutexes are not 'recursive'.  This means that a
> thread blocks when it tries to lock a mutex that it already has
> locked.
>
> I think we should make our mutexes be recursive by default.  Expecting
> to block when locking a mutex that is already lcoked by one self is
> not very useful, since no one can unlock that mutex (excepts asyncs).

Though people coming from POSIX threads (at least under glibc) will be
used to having to explicitly ask for recursive mutexes, and at least
at the C level, there's apparently an efficiency issue involved.
Would it be hard to provide both and let the user select at creation
time?

> The only good argument against recursive mutexes that I can think of
> is a tiny performance gain since you don't need to do some checking.

I guess to some extent it would depend on how tiny the gain would be :>

> SRFI-18 specifies non-recursive mutexes and allows non-owning threads
> to unlock a mutex.  Such uses of a mutex are, in my view, a mockery of
> condition variables should be avoided.

Well you certainly could use a condition variable instead of a mutex
here, but I would suspect that in cases where you just want to wake
someone else up, a mutex others can unlock would be lighter weight.
With a condition variable you have to have both a mutex and the
condition variable.

It sounds like the SRFI-18 mutexes are just POSIX Semaphores with one
token, and POSIX Semaphores are more flexible, and seem only trivially
harder to implement -- likely not much more than adding an integer
counter and a few trivial numeric comparisons.  If so, I'd rather have
a POSIX Semaphore and provide a trivial wrapper that satisfies
SRFI-18.

In POSIX mutexes are pretty low-level -- they're more or less just an
atomic lock -- that makes sense since they're the simplest portable
sync type.  Semaphores and Condition Variables are for anything more
than the most basic operations, and even there (as you and I talked
about), there are no FIFO fairness guarantees, so you're often faced
with building your own sync operations on top of them.

One thing that the POSIX model has going for it is exposure -- I
suspect a lot of people are familiar with how the API works, so my
default inclination would be to follow that API whenever there's not a
good reason not to.  We may also want to add some enhancements like
FIFO guarantees that don't contradict the standard, but that's a
separate question.

IMO thread programming is hard.  Writing correct algorithms using
threads can be hard, and if someone already has something they've
written using the POSIX semantics that works, it will be a lot easier
to migrate to another language if the semantics are similar.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: Recursive mutexes?

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> One thing that the POSIX model has going for it is exposure -- I
> suspect a lot of people are familiar with how the API works, so my
> default inclination would be to follow that API whenever there's not a
> good reason not to.

Oh, and I probably should have mentioned, I mean most likely we deal
with a *subset* of the posix API since I don't know that we want to
accomodate everything like the thread cancellation stuff, etc...

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: Recursive mutexes?

[Tom Lord]

Sorry for a naive question but:

What Guile-using apps currently use threads?  Is it too late to just
rip them out?


     > IMO thread programming is hard.  

IMO, you are right.

In my "dream scheme" system, I'm thinking they aren't worth the
effort.  They slow down access to the store and complicate
programming.  I don't even want to think about how to reconcile them
with continuations, dynamic-wind, or fluids.

I do want multiple interpreters (without a shared store) in separate
threads.  I do want low-level routines running in separate threads
(e.g., give a CPU to I/O or to reving cellular automata generations).   
But I'm having trouble seeing Scheme semantics as other than "optimal
for SISD".


-t




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

Re: Recursive mutexes?

[Thomas Bushnell, BSG]

Tom Lord <lord@regexps.com> writes:

> In my "dream scheme" system, I'm thinking they aren't worth the
> effort.  They slow down access to the store and complicate
> programming.  I don't even want to think about how to reconcile them
> with continuations, dynamic-wind, or fluids.

It seems to me that we should not decide that a problem is too hard to
solve well before trying.

> I do want multiple interpreters (without a shared store) in separate
> threads.  I do want low-level routines running in separate threads
> (e.g., give a CPU to I/O or to reving cellular automata generations).   
> But I'm having trouble seeing Scheme semantics as other than "optimal
> for SISD".

How will these different interpreters share data?


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

Re: Recursive mutexes?

[Tom Lord]

   Tom Lord <lord@regexps.com> writes:

   > In my "dream scheme" system, I'm thinking they aren't worth the
   > effort.  They slow down access to the store and complicate
   > programming.  I don't even want to think about how to reconcile them
   > with continuations, dynamic-wind, or fluids.

   It seems to me that we should not decide that a problem is too hard to
   solve well before trying.

Trying or thinking through, sure.   I just wanted to put the
alternative on the table -- not discourage careful consideration of
all alternatives.



   > I do want multiple interpreters (without a shared store) in separate
   > threads.  I do want low-level routines running in separate threads
   > (e.g., give a CPU to I/O or to reving cellular automata generations).   
   > But I'm having trouble seeing Scheme semantics as other than "optimal
   > for SISD".

   How will these different interpreters share data?


Dunno.  Lots of options exist.  Here's a few:

1) through optimizedj intra-process I/O

2) through segregated data structures that can be passed back and
   forth between threads (a high-level "segmented" store).

3) through a subset of values that _are_ shared.

3a) through java objects

3b) through objects of types defined by extensions to guile

-t


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

Re: Recursive mutexes?

[Tom Lord]

       > Trying or thinking through, sure.   

And, to be fair, sometimes the best way to think something through is
in parallel with trying to implement it -- no disrespect intended
towards people hacking on Guile threads.

-t


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

Re: Recursive mutexes?

[Thomas Bushnell, BSG]

Tom Lord <lord@regexps.com> writes:

>        > Trying or thinking through, sure.   
> 
> And, to be fair, sometimes the best way to think something through is
> in parallel with trying to implement it -- no disrespect intended
> towards people hacking on Guile threads.

I think that problems like this require a somewhat more "daring"
approach.  For example, threads need not slow down access to the
store.  

Threads in C do not, in general, slow down access.  Only when there is
an actual lock necessary do they slow anything down.  The same thing
should be true in a *good* scheme system.

In a safe language like Scheme, this probably means that you have to
be willing to accept arbitrary preemption.  And, indeed, I knew this
way back when guile was a dream, and said to people "if there are
going to be threads, use real OS (i.e., preemptible on arbitrary
instructions) threads".  I was initially told "yeah, we'll do that",
and then it didn't happen, because "it's too hard".

Well, yeah, it's hard.  But I don't think it's anything like
unsolvable.  It's actually not that hard at all if you think carefully
about it and decide exactly what guarantees need to be provided and
when.

That's one of your issues about why "threads are bad".  I don't see it
as any reason why threads are bad, but rather about why the (sadly)
normal implementation is bad.

Thomas





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

Re: Recursive mutexes?

[Tom Lord]

     >> IMO thread programming is hard.  


     > In my "dream scheme" system, I'm thinking they aren't worth the
     > effort.  They slow down access to the store and complicate
     > programming.  I don't even want to think about how to reconcile them
     > with continuations, dynamic-wind, or fluids.


Oh yea...

that also raises one intresting idea:  reconciling java with scheme.

Java semantics seem to me much, much nicer for MIMD (just intuitively,
no elaborate argument).   

Java also seems like a plausible variation on what you'd get if you
wanted to take a subset of Scheme and add declarations.   It's object
model is a little heavy and weird, but it's also pretty simple.

So maybe one approach is a split store: thread-private storage for
Scheme data; shared storage for java-ish objects.

There'd be plenty of other benefits to using Java as "typed Scheme
subset" besides threads, too.

-t




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

Re: Recursive mutexes?

[Neil Jerram]

>>>>> "Tom" == Tom Lord <lord@regexps.com> writes:

    Tom> Java semantics seem to me much, much nicer for MIMD (just intuitively,
    Tom> no elaborate argument).   

What are MIMD and SISD?

I like Java's synchronized/notify/wait model very much, but how would
you express it in Scheme without adding lots of Java-ish class
declaration stuff?  How would it map onto GOOPS?

        Neil



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

Re: Recursive mutexes?

[Tom Lord]

	Tom> Java semantics seem to me much, much nicer for MIMD (just intuitively,
	Tom> no elaborate argument).   

	What are MIMD and SISD?

"multiple/single instruction; multiple/single data" -- i.e. ordinary
multi- and single CPU systems.   (I'm not sure anyone really bothers
to say SISD -- I made it up.   People do say SIMD.)

	I like Java's synchronized/notify/wait model very much, but
	how would you express it in Scheme without adding lots of
	Java-ish class declaration stuff?  

The suggestion is that you _do_ look into combining the languages.

One way to do it is kawa-style in which (caution: this is from old
memory) every scheme value is a java object and vice versa.  That
isn't what I was suggesting.

I was suggesting something more layered: Another way to do it is to
have a universe of java-ish objects, shared between threads, and one
store of Scheme objects per thread.  Fine-grain multi-threaded parts
in java-ish; course-grain in Scheme, coordinating via call-outs to
java-ish.  If Guile is currently layered "Scheme over C", this would
make it layered "Scheme over both C and java-ish-over-C".

If Emacs were done that way, for example, you might wind up with
low-level buffers and redisplay in java-ish (redisplay in its own
thread); and scheme-extensible threads for handling user interaction,
subprocess mgt, redisplay customization, etc.

Part of the idea here was to be able to leverage other people's
java-ish implementation work in an easy (heh) way.

Even though it's not a Schemishly minimalist approach, I think this
might actually be a nice model to use when building programs (as in,
"easy to write good, correct, maintainable programs with").


	How would it map onto GOOPS?

Doesn't goops have enough of a MOP to support optimized
representations given restrictions on the optimized types?

-t


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

Re: Recursive mutexes?

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> > I think we should make our mutexes be recursive by default.  Expecting
> > to block when locking a mutex that is already lcoked by one self is
> > not very useful, since no one can unlock that mutex (excepts asyncs).
> 
> Though people coming from POSIX threads (at least under glibc) will
> be used to having to explicitly ask for recursive mutexes,

I am confused by the libc docs: what is a "timed" mutex?  Is it
recursive or not?  I just checked a little test program and the
default pthread mutexes seem to be recursive, on GNU/Linux.  "Fast"
mutixes are not resursive but you have to ask for them.

> Would it be hard to provide both and let the user select at creation
> time?

No.  But what about having two sets of locking/unlocking functions:
one that behaves recursivly, and one that doesn't?

> > SRFI-18 specifies non-recursive mutexes and allows non-owning threads
> > to unlock a mutex.  Such uses of a mutex are, in my view, a mockery of
> > condition variables should be avoided.
> 
> Well you certainly could use a condition variable instead of a mutex
> here, but I would suspect that in cases where you just want to wake
> someone else up, a mutex others can unlock would be lighter weight.
> With a condition variable you have to have both a mutex and the
> condition variable.

And for a good reason, no?

-- 
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: Recursive mutexes?

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> I am confused by the libc docs: what is a "timed" mutex?  Is it
> recursive or not?

Good question -- I had wondered if the two things were orthogonal,
i.e. you could select create (mutex, RECURSIVE | TIMED), but from
looking at the docs it's not clear to me, but they don't look
orthogonal.  The timed mutex was actually news to me -- I hadn't
realized they'd added those.

(I think perhaps I've been thinking more of the older threads
 implementation which wasn't quite the same as posix.)

> I just checked a little test program and the default pthread mutexes
> seem to be recursive, on GNU/Linux.  "Fast" mutixes are not
> resursive but you have to ask for them.

Hmm.  Now I'm confused.  I'd read the libc docs and it had looked to
me like fast mutexes were the default (they used to be), but now I see
that the libc docs say that fast mutexes are the default in the
*LinuxThreads* implementation.  The libc docs unfortunately don't seem
to say much about when you would be using the LinuxThreads
implementation as opposed to a posix one.  (have to go poke around and
see what the deal is these days)

> No.  But what about having two sets of locking/unlocking functions:
> one that behaves recursivly, and one that doesn't?

You could do that.  I think perhaps the reason posix doesn't is
because the non-recursive ones may be more efficient on a given
platform, and some people are be watching every cycle.  If that's the
only issue, then we may not care.

>> Well you certainly could use a condition variable instead of a mutex
>> here, but I would suspect that in cases where you just want to wake
>> someone else up, a mutex others can unlock would be lighter weight.
>> With a condition variable you have to have both a mutex and the
>> condition variable.
>
> And for a good reason, no?

Not sure I follow.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: Recursive mutexes?

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> >> Well you certainly could use a condition variable instead of a mutex
> >> here, but I would suspect that in cases where you just want to wake
> >> someone else up, a mutex others can unlock would be lighter weight.
> >> With a condition variable you have to have both a mutex and the
> >> condition variable.
> >
> > And for a good reason, no?
> 
> Not sure I follow.

I meant: there is a good reason that waiting on a condition variable
requires you to have a locked mutex that is the atomically unlocked.
Without this, I guess you will have a hard time avoiding race
conditions.  Using mutexes in a strange way to simulate this is
probably wrong.

-- 
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: Recursive mutexes?

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> I meant: there is a good reason that waiting on a condition variable
> requires you to have a locked mutex that is the atomically unlocked.
> Without this, I guess you will have a hard time avoiding race
> conditions.  Using mutexes in a strange way to simulate this is
> probably wrong.

Ahh, right.  I presume you mean the deadlock case of blocking after
you've already been signalled -- yeah mutexes (at least posix style)
aren't the best thing there, but I'd generally use a 0 token sempahore
for that.  Then if you're the one about to block, the signaller will
either already have deposited the token, or will after you block.

I have to keep reminding myself that mutexes aren't semaphores here.
I keep forgetting that because I did a whole lot of thread programming
in a system where we arranged for mutexes to be a special case
(one-token) semaphore.  This meant it was supposed to be OK for others
to signal, etc.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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