[fpc-pascal] Semaphore problems

[Burkhard Carstens]

Am Dienstag, 25. Juli 2006 10:46 schrieb Micha Nelissen:
> 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.
>
> >> Got confused a bit :-). Reread the thread, and think your
> >> latest implementation as posted here is ok.
> >
> > No, it's not. As usually I should sit down with pencil, paper, a
> > cup of
>
> I mean the idea for the recursive locking is ok. I was confused by
> the whole 'owning' part. Locks don't own threads in my mind, so I
> assumed you got that right. Alas, no :-). Also problematic is posting
> only partly updates to a function. Then we forget the other, also
> critical part.
>
> function Recursive_Mutex.Lock:...;
> begin
>    // Owned by current thread?
>    if CurrentThreadId <> self.ThreadId then
>    begin
>       result := pthread_mutex_lock (self...);
>       if result <> 0 then exit;
>       self.ThreadId := CurrentThreadId;
>       self.Count := 1;
>    end else begin
>       Inc(self.Count);
>    end;
>    result := SUCCESS;
> end {Mutex.Lock};
>
> function Recursive_Mutex.Unlock: ...;
> begin
>   if CurrentThreadId <> self.ThreadId then
>     exit(ENOTOWN);
>   assert(self.Count > 0);
>   dec(self.Count);
>   if self.Count = 0 then
>   begin
>     self.ThreadId := 0; // a threadid that does not occur in system
>     pthread_mutex_unlock(self...);
>   end;
>   result := SUCCESS;
> end;
>
> I don't see the need for Owner_Check_Lock anymore ? :-)

You have to prevent that 2 concurrent threads call lock simultanously, 
so you have to take an internal lock before touching internal vars like 
self.ThreadID ?

Burkhard