On Tuesday 25 July 2006 08:46, Micha Nelissen wrote: > Vinzent Hoefler wrote: > >> Ehm, no. > > > > Ehm, yes. I was being ironic here. Of course, the action of > > checking the counter and locking/unlocking the associated mutex > > must be atomic. > > But here they are not associated, they're protected by owner_lock, as > you said.
Yes. That's what would have made the whole operation atomic. > I mean the idea for the recursive locking is ok. Well, in the end it's functionality that counts. Ideas I got. Lots. > I was confused by the whole 'owning' part. Locks don't own threads in > my mind, so I assumed you got that right. Yes, that's right, locks don't own threads. But threads own locks. :) > Alas, no :-). Also problematic is posting > only partly updates to a function. Then we forget the other, also > critical part. Yepp. It wasn't yet meant to be committed to svn, you know? ;) > function Recursive_Mutex.Lock:...; [...] > > function Recursive_Mutex.Unlock: ...; [...] > > I don't see the need for Owner_Check_Lock anymore ? :-) Yes, that looks about right. ;-) Except perhaps for the possible glitch I mentioned in my other mail. Don't know, if we can ignore it for now or simply assume that (up to) 32-Bit-variables always *are* atomic types. Vinzent. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
