Branch: refs/heads/master
Home:   https://github.com/D-Programming-Language/phobos

Commit: 99336f35cd98a56893f5517c1ba2a414abfc7fc1
    https://github.com/D-Programming-Language/phobos/commit/99336f35cd98a56893f5517c1ba2a414abfc7fc1
Author: dsimcha <dsimcha at gmail.com>
Date:   2011-05-07 (Sat, 07 May 2011)

Changed paths:
  M std/parallelism.d

Log Message:
-----------
Fix bug in std.parallelism unittest.  (All code changes are in unit tests, not "real" code.)  Basically, appending to arrays with ~= is not thread safe even with manual synchronization.

On Sat, 07 May 2011 07:39:52 -0400, <noreply at github.com> wrote:

> Branch: refs/heads/master
> Home:   https://github.com/D-Programming-Language/phobos
>
> Commit: 99336f35cd98a56893f5517c1ba2a414abfc7fc1
>     https://github.com/D-Programming-Language/phobos/commit/99336f35cd98a56893f5517c1ba2a414abfc7fc1
> Author: dsimcha <dsimcha at gmail.com>
> Date:   2011-05-07 (Sat, 07 May 2011)
>
> Changed paths:
>   M std/parallelism.d
>
> Log Message:
> -----------
> Fix bug in std.parallelism unittest.  (All code changes are in unit tests, not "real" code.)  Basically, appending to arrays with ~= is not thread safe even with manual synchronization.

Do you know/remember the cause of this? (i.e. are we still using a local look-up cache for capacity?)

On 5/7/2011 2:01 PM, Robert Jacques wrote:
> Do you know/remember the cause of this? (i.e. are we still using a local look-up cache for capacity?)

Yes, that's the issue.  I changed a few cases in the std.parallelism unittest a long time ago but forgot to change the rest because they never failed in practice even if they were wrong in theory.  This failure reminded me that they needed to be fixed.

The cache lookup is not exactly for capacity.? The cache stores the block info (block flags, block start, and block size) for the memory block.? This is the data that is looked up from the GC while holding the global lock.


Specifically, in this case, the cache is NOT to blame.? The block info is not changing, so looking it up via cache or directly from the GC is not going to make a difference.

However, appending to non-shared arrays in multiple threads is not supported.? I'm not sure how it could be done, because the cache relies so much on the fact that the type tells you it's thread local.? Any ideas?? It would be nice to solve this, because this includes appending to __gshared arrays.


BTW, you can turn off the caching by returning null from __getBlkInfo in rt/lifetime.d, and commenting out the body of __insertBlkInfoCache.? This can at least help you narrow down whether it's a cache problem or not.? I probably should make? a version for testing this.


-Steve




>________________________________
>From: Robert Jacques <sandford at jhu.edu>
>To: Discuss the phobos library for D <phobos at puremagic.com>
>Sent: Saturday, May 7, 2011 2:01 PM
>Subject: Re: [phobos] [D-Programming-Language/phobos] 99336f: Fix bug in std.parallelism unittest. (All code ch...
>
>On Sat, 07 May 2011 07:39:52 -0400, <noreply at github.com> wrote:
>
>> Branch: refs/heads/master
>> Home:? https://github.com/D-Programming-Language/phobos
>> 
>> Commit: 99336f35cd98a56893f5517c1ba2a414abfc7fc1
>>? ? https://github.com/D-Programming-Language/phobos/commit/99336f35cd98a56893f5517c1ba2a414abfc7fc1
>> Author: dsimcha <dsimcha at gmail.com>
>> Date:?  2011-05-07 (Sat, 07 May 2011)
>> 
>> Changed paths:
>>?  M std/parallelism.d
>> 
>> Log Message:
>> -----------
>> Fix bug in std.parallelism unittest.? (All code changes are in unit tests, not "real" code.)? Basically, appending to arrays with ~= is not thread safe even with manual synchronization.
>
>Do you know/remember the cause of this? (i.e. are we still using a local look-up cache for capacity?)
>_______________________________________________
>phobos mailing list
>phobos at puremagic.com
>http://lists.puremagic.com/mailman/listinfo/phobos
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110516/5ce63066/attachment.html>