[fpc-devel] Multithreading wait for

[Mattias Gärtner]

Zitat von Vinzent Höfler <JeLlyFish.software at gmx.net>:

> Mattias Gaertner wrote:
> > On Wed, 03 Dec 2008 19:41:12 +0100
> > Vinzent Höfler <JeLlyFish.software at gmx.net> wrote:
> >
> > If I understand RTLEventWaitFor correct, then it waits until another
> > thread calls RTLeventSetEvent.
>
> Unless it's already signalled, then it should run right through.

Yes, that works under Linux. But the documentation does not mention it, so I'm
not sure if this works under all platforms.
Maybe some other OS users can try if the following code runs through:

var
  e: PRTLEvent;
begin
  e:=RTLEventCreate;
  RTLeventSetEvent(e);
  RTLeventWaitFor(e);
  RTLeventdestroy(e);
end;

If this is guaranteed then my problem is already solved and the code work as it
is. But then the documentation must mention it.
Who knows if this is a documentation bug or a linux bug?


> > So I must check *before* calling RTLEventWaitFor, that some other thread
> > is running, must I not?
>
> No, assuming RTLEvent implements a persistent signal, not a transient
> one. I am not 100% sure here (so someone should check the source), but I
> remember that there were two versions (mimicking the Windows-Events),
> depending on how one would set them up. I implemented my own versions
> some time ago (fpc2.0.0), but that was due to some bugs and quirks in
> fpc's implementation, so I'm not really up to date if those are fixed
> now for all platforms.
>
> >>> The problem is the gap between LeaveCriticalSection and
> >>> RTLeventWaitFor. During this time the other threads may finish. So
> >>> there is no one left to wake up the waiting thread.
> >> So your asking the wrong question. You don't want an efficient wait
> >> loop, you want a wait loop free from race conditions.
> >
> > :)
> > I know how to do a race condition free loop inefficiently using a spin
> > lock. My question is, if it can be done race condition free and
> > efficiently, to allow switching thousands of times a second without busy
> waiting.
>
> That's what it should do (although the term "efficiently" may depend on
> some other factors like number of processing units, threads waiting,
> average wait time and such).
>
> >> Well, depending on what your checks do, you may not even need the
> >> critical section if you reverse the logic. Either all checked threads
> >> are finished or they aren't. If the state changed during the check,
> >> the check code will be invoked immediately, because the event will
> >> already be signalled again.
> >
> > The critical section is needed, because after a thread finished some
> > work it starts some other work.
>
> Well, in that case... Another solution would be to provide specific
> events for the waiting threads, but this requires quite some more amount
> of administrative work, so in the end it may even turn out to be less
> efficient. ;)
>
>
> Vinzent.
>
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>


------------------
Powered by NetMail