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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
