[fpc-pascal] Semaphore problems

Vinzent Hoefler 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 mailing list