On Fri, Oct 15, 2010 at 9:24 AM, Jonas Maebe <jonas.ma...@elis.ugent.be> wrote: > You replaced a bunch of semaphore create/lock/unlock/destroy operations with > calls to a function that does not do anything.
I did not. I REMOVED create/destroy/lock/unlock. I ADDED calls to the ThreadManager's own functions for thread Resume and Suspend. Did you try executing the suspend command? What happened? > That barrier has nothing to do with "set values of variables before calling > the inherited create method to their own creation" (although it's not > entirely clear to me you mean by that). If you set values that the child > thread will read after that thread has already been created, this memory > barrier will not help either. That barrier is again about memory write > ordering, which could cause the newly started thread to not see all writes > performed by the parent thread *before* creating the child thread. Other than waiting for the values to be committed, I just don't see it's value. > And the reason that's it's probably not required, is because there's so much > code in between that it's unlikely that any of those writes would still be > outstanding at that point. It's not "for the few that don't understand how > to create a thread". Exactly. The other code being what? _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
