[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