Re: [v3] __pool_alloc rework

[Carlo Wood <carlo at alinoe dot com>]

On Sat, Jun 19, 2004 at 09:02:34PM +0530, Dhruv Matani wrote:
> How can that be implemented? For the user, the allocate/deallocate
> functions will appear as atomic operations, so the lock will never be
> held across 2 different function calls.

Not in my case.

> So, I guess there is no way to know if the *current* thread holds the
> lock. However, to know whether other threads hold the lock should be
> trivial. Use pthread_mutex_trylock().

Which also can be used for the current thread.

> Quote:
> *) the accessor should return true if the current thread holds the lock, and
> can return true if another thread holds the lock more or less at the moment
> of the call to the accessor (so, a simple non-atomic test whether or not
> the lock is locked from within the accessor suffices: 
> 
> if the current thread
> holds the lock then that will always work).
> 
> ??? I didn't quite get this last sentence.

Normally it makes no sense to ask if a mutex is locked for ANOTHER thread
unless you also take obtain that lock (if it wasn't locked) - thus, trylock.

However - I don't want this accessor to set the lock. As a result it is a
fuzzy return value:
- If the current thread holds the lock, it MUST returns true.
- If the current thread does not hold the lock it may return anything.

However - I don't want an implementation as:  bool accessor { return true; }
cause that won't help a bit.  If at all possible, false should be returned
when it is detectable that the lock is not hold by the current thread.
A working implementation would be (in pseudo code):

bool accessor { bool locked = !trylock(); if (!locked) { unlock(); } return locked; }

But someone might be able to think of a better solution...

-- 
Carlo Wood <carlo@alinoe.com>