nested mutexes

[Jeff Trawick <tr...@attglobal.net>]

I guess I'm a day late and a dollar short as usual, but here goes
anyway... 

1. It looks to me that on Unix APR mutexes are always nesting if
   APR_HAS_THREADS and APR mutexes are never nesting (subject to their
   underlying implementation of course).  This is not cool.

   How is the application supposed to approach this?  Either the use
   of the mutex requires nesting or it doesn't, regardless of how APR
   or the application are built/designed w.r.t. threads.

2. Why doesn't the app have to request that a particular mutex support
   nesting?  If the app isn't designed to need the nesting then
   allowing a nested mutex acquire to succeed would seem to hide an
   application problem.

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Re: nested mutexes

[Dale Ghent <da...@elemental.org>]

On Tue, 19 Jun 2001, David Reid wrote:

| If we already own a lock we should be able to lock it again shouldn't we?

In pthread world, A mutex can only be recursively locked if
PTHREAD_MUTEX_RECURSIVE is set in the mutex's attributes, which, from a
glance at the lock code, we dont seem to set. In absence of that on
solaris, the default result recursive locking is "undefined" behaviour.

/dale

Re: nested mutexes

[David Reid <dr...@jetnet.co.uk>]

If we already own a lock we should be able to lock it again shouldn't we?

Part of the problem was my initial assumption that if we didn't have threads
we didn't have locks, but of course we do :) Jeff's suggestion of using the
pid was a good one I think to get us around this problem.  Are you adding
that Jeff or did you want me to?

david

> On 19 Jun 2001, Jeff Trawick wrote:
>
> | no, by "nested mutex" I mean that this is allowed
> |
> | Thread A holds mutex 1
> | Thread A obtains mutex 1 again
> |
> | what I call "nested mutex acquire" is sometimes called "recursive
> | mutex acquire"
>
> Wouldnt an attempt to aquire a mutex that is already owned (by the
> calling thread or another thread) fail with EDEADLK, so anything obtaining
> something more than once is not possible without error?
>
> Perhaps something like a "mutex keychain" would be good to help a thread
> keep track of mutexes it currently owns/are globaly owned so that attempts
> to aquire owned ones would be thwarted?

Re: nested mutexes

[Dale Ghent <da...@elemental.org>]

On 19 Jun 2001, Jeff Trawick wrote:

| no, by "nested mutex" I mean that this is allowed
|
| Thread A holds mutex 1
| Thread A obtains mutex 1 again
|
| what I call "nested mutex acquire" is sometimes called "recursive
| mutex acquire"

Wouldnt an attempt to aquire a mutex that is already owned (by the
calling thread or another thread) fail with EDEADLK, so anything obtaining
something more than once is not possible without error?

Perhaps something like a "mutex keychain" would be good to help a thread
keep track of mutexes it currently owns/are globaly owned so that attempts
to aquire owned ones would be thwarted?

/dale

Re: nested mutexes

[Jeff Trawick <tr...@attglobal.net>]

Justin Erenkrantz <je...@ebuilt.com> writes:

> On Fri, Jun 15, 2001 at 05:59:14AM -0400, Jeff Trawick wrote:
> > Jeff Trawick <tr...@attglobal.net> writes:
> > 
> > > 1. It looks to me that on Unix APR mutexes are always nesting if
> > >    APR_HAS_THREADS and APR mutexes are never nesting (subject to their
> > >    underlying implementation of course).  This is not cool.
> > 
> > I meant to say "It looks to me that on Unix APR mutexes are always nesting if
> > APR_HAS_THREADS and APR mutexes are never nesting (subject to their
> > underlying implementation of course) if !APR_HAS_THREADS."
> 
> Can you clarify what you mean by nesting?
> 
> Do you mean:
> 
> Thread A holds one mutex (say in apr_sendfile)
> Thread A also obtains another mutex later on (say in apr_pool)

no, by "nested mutex" I mean that this is allowed

Thread A holds mutex 1
Thread A obtains mutex 1 again

what I call "nested mutex acquire" is sometimes called "recursive
mutex acquire"

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Re: nested mutexes

[Justin Erenkrantz <je...@ebuilt.com>]

On Fri, Jun 15, 2001 at 05:59:14AM -0400, Jeff Trawick wrote:
> Jeff Trawick <tr...@attglobal.net> writes:
> 
> > 1. It looks to me that on Unix APR mutexes are always nesting if
> >    APR_HAS_THREADS and APR mutexes are never nesting (subject to their
> >    underlying implementation of course).  This is not cool.
> 
> I meant to say "It looks to me that on Unix APR mutexes are always nesting if
> APR_HAS_THREADS and APR mutexes are never nesting (subject to their
> underlying implementation of course) if !APR_HAS_THREADS."

Can you clarify what you mean by nesting?

Do you mean:

Thread A holds one mutex (say in apr_sendfile)
Thread A also obtains another mutex later on (say in apr_pool)

So, a thread may possibly obtain more than one mutex?  But, the mutex
handles will be different, right?  So, it shouldn't deadlock on itself.

I do think how APR (and httpd) uses locks in general needs a serious 
revisit.

Now, that the school year is done (yay!), I'll probably have time to 
look at this soon.  -- justin

Re: nested mutexes

[Jeff Trawick <tr...@attglobal.net>]

Jeff Trawick <tr...@attglobal.net> writes:

> 1. It looks to me that on Unix APR mutexes are always nesting if
>    APR_HAS_THREADS and APR mutexes are never nesting (subject to their
>    underlying implementation of course).  This is not cool.

I meant to say "It looks to me that on Unix APR mutexes are always nesting if
APR_HAS_THREADS and APR mutexes are never nesting (subject to their
underlying implementation of course) if !APR_HAS_THREADS."

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...