I disagree. I've never had problems with setting values inside boolean arrays in multi-threaded environments. The memory is already allocated. Setting the value does not cause memory re-allocation, which would be the only source of problems. But of course just because I didn't experience problems in the past with this does not mean I won't with a future. ;-)
On Fri, Oct 8, 2010 at 9:04 AM, Jonas Maebe <jonas.ma...@elis.ugent.be> wrote: > > On 08 Oct 2010, at 15:57, Andrew Brunner wrote: > >> A better way of achieving this is looking at the collection of threads >> you have. Set your own booleans for Finished or if they >> freeonterminate you will need to create an >> TCompletes=Array[0..threadcount] of boolean. And as the threads free >> set the variable of TCompletes to true. Then you can poll the >> Completes to see if they are all true. >> >> There are a million ways to accomplish safe thread usage without >> waitfor... > > Yes, but the alternatives above are only safe if you only use atomic > operations (which could be quite slow in case of an array of booleans due to > the atomic reservation granularity), or if you add proper memory barriers > everywhere. > > > Jonas > _______________________________________________ > fpc-pascal maillist - fpc-pas...@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
