On Wed, 03 Dec 2008 19:41:12 +0100 Vinzent Höfler <[EMAIL PROTECTED]> wrote:
> Mattias Gärtner wrote: > > > The situation: > > There are m threads working in parallel on n chunks of work (n>=m). > > The n chunks are indexed 0..n-1. > > Sometimes one thread needs the result of some of the lower indexed > > chunks. For example the chunk number 5 needs chunks 0..2. > > So I have a function WaitForIndex(LowerIndex: integer) which should > > wait until all chunks with less or equal to LowerIndex have > > finished. > > > > My current approach is this: > > EnterCriticalSection (try..finally) > > Check if all lower chunks have finished, if yes then exit > > LeaveCriticalSection > > RTLeventWaitFor(AnEventOfTheCurrentThread); > > Why don't you do it the other way around? > > wait_loop: > > RTLEventWaitFor (SomeChunkHasFinishedEvent); > // EnterCriticalSection; > State of chunks changed -> > so check if all lower parts are ready, if yes then exit > // LeaveCriticalSection; > > goto wait_loop; > > This way, the loop only gets awakened once something changed, you > check the state (in an atomic way, if at all necessary) and go back. > In case another event occured between the RTLEventWaitFor and > EnterCriticalSection it will go through a second time immediately. If I understand RTLEventWaitFor correct, then it waits until another thread calls RTLeventSetEvent. So I must check *before* calling RTLEventWaitFor, that some other thread is running, must I not? It's a pool of threads. > > 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. > > Moving the RTLeventWaitFor into the CritialSection creates a > > deadlock. I can use the timeout of RTLeventWaitFor and check in > > intervals, but criticalsections and low response times don't fit > > together. > > 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. Mattias _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel