Am 13.10.2010 00:51, schrieb Andrew Brunner:
This test case illustrates a FPC memory leak.
What makes you think so? Internally freed memory is not immediatly
released to the OS as well.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
Since the number of threads is set at compile time, I didn't expect to
see the much memory creep. The resource monitor for the process shows
about 15Mb of memory used. When the first group of 50 threads was
created and ran that climbed another 5 to about 20MB. Then every time
the system created
On 13 Oct 2010, at 00:51, Andrew Brunner wrote:
The interesting thing I have noticed was that Arrays[n] of boolean can
be used without memory barriers. There is not one lock associated
with the boolean arrays and it always proves non-problematic on a 6
core system with 4gig ram. There are
On 13 Oct 2010, at 15:27, Jonas Maebe wrote:
1) on entry of the critical section protected by this variable,
you can have problems, because this sequence:
locked:=true;
local:=shared_global_var;
Of course, you normally need an atomic operation here to set locked
to true (otherwise
On Wed, Oct 13, 2010 at 8:27 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
1) on entry of the critical section protected by this variable, you can
have problems, because this sequence:
locked:=true;
local:=shared_global_var;
may actually be executed in this order:
