On Tuesday 25 July 2006 06:40, Micha Nelissen wrote:
> Vinzent Höfler wrote:
> > because we assume it's non-recursive, that was the whole point. So
> > we should *first* check the count and then may lock/unlock the
> > mutex accordingly.
>
> Note that these two actions must be atomic.
Oh, really?
> This is what the TryLock is for.
No, that's what the "Owner_Check_Lock" in my posted code would be for in
the first place. But you're right, TryLock makes it possibly easier to
detect/handle failures.
So the code from
> // Now try locking the real mutex.
should actually be more like:
| // First encounter? So lock it actually.
| if self.Count = 0 then
| begin
| // This should *always* succeed, because we're the owning
| // thread (we've just checked it, right?) and we didn't lock it
| // yet according to "Count".
| // Thinkable ways how this can fail is if somebody has direct
| // access to the actual pthread mutex inside here or we
| // fuc^Wmessed up the counter somehow ...
| if pthread_mutex_trylock (self...) <> 0 then
| // Our real mutex couldn't be locked!? This *is* strange.
| exit (FAILURE);
| end {if};
|
| // Alright, we got it. Mutex is locked (or at least, it *should* be
| // already), so count up.
| self.Count := self.Count + 1;
| self.Owner_Check.Unlock;
| exit (SUCCESS);
A pthread_mutex_trylock alone wouldn't actually help on a non-recursive
"real" mutex. Because: if it's already locked I still don't know if it
belongs to the current thread, but precisely that knowledge is needed
to implement the recursive one on top of a non-recursive.
Vinzent.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
