[v3] __pool_alloc rework
Carlo Wood
carlo@alinoe.com
Sat Jun 19 18:47:00 GMT 2004
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>
More information about the Libstdc++
mailing list