[fpc-pascal] Semaphore problems
JeLlyFish.software at gmx.net
Tue Jul 25 12:10:12 CEST 2006
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
More information about the fpc-pascal