[fpc-pascal] Semaphore problems

Micha Nelissen micha at neli.hopto.org
Tue Jul 25 10:46:36 CEST 2006


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 ? :-)

Micha



More information about the fpc-pascal mailing list