On Wednesday, 29 November 2017 at 17:03:42 UTC, Steven Schveighoffer wrote:
> On 11/29/17 11:13 AM, Wanderer wrote:
>> I'm trying to simulate a race condition in D with the following code:
>> 
>> (https://run.dlang.io/is/RfOX0I)
>
> One word of caution, I think the running of your code on run.dlang.io is cached. Refreshing doesn't make it re-run.
>
> https://run.dlang.io/is/k0LhQA
>
> -Steve

I was using this just for the reference, as I've noticed caching as well.
Thanks Steve, for spending time and actually hitting a race!

On Wednesday, 29 November 2017 at 17:03:42 UTC, Steven Schveighoffer wrote:
> On 11/29/17 11:13 AM, Wanderer wrote:
>> I'm trying to simulate a race condition in D with the following code:
>> 
>> (https://run.dlang.io/is/RfOX0I)
>
> One word of caution, I think the running of your code on run.dlang.io is cached. Refreshing doesn't make it re-run.
>
> https://run.dlang.io/is/k0LhQA
>
> -Steve

Ah good catch.

On 2017-11-29 17:13, Wanderer wrote:
> I'm trying to simulate a race condition in D with the following code:
I'm not sure what your end goal is but perhaps you could try to see if the LLVM thread sanitizer [1] can be used with LDC. The thread sanitizer can identify race conditions even though they're not actually triggered [2].

It can be quite difficult to simulate a race condition because x86 has an almost strong memory model.

[1] https://clang.llvm.org/docs/ThreadSanitizer.html
[2] https://developer.apple.com/videos/play/wwdc2016/412/ 16:00

-- 
/Jacob Carlborg

On Wednesday, 29 November 2017 at 16:13:13 UTC, Wanderer wrote:
> static void getId(shared IdGen!(MyId)* g)
> {
>     writeln("next: ", g.next());
>     writeln("next: ", g.next());
> }

writeln synchronizes on stdout, so your code is mostly serialized, good example of a very subtle race condition.

On 12/4/17 4:09 AM, Kagamin wrote:
> On Wednesday, 29 November 2017 at 16:13:13 UTC, Wanderer wrote:
>> static void getId(shared IdGen!(MyId)* g)
>> {
>>     writeln("next: ", g.next());
>>     writeln("next: ", g.next());
>> }
> 
> writeln synchronizes on stdout, so your code is mostly serialized, good example of a very subtle race condition.

Well, this is just why you don't see output items that are mixed lines (i.e. "nenext: 1\nxt: 2\n" instead of "next: 1\nnext: 2\n")

The next calls are not synchronized.

-Steve

A lock on stdout works as a barrier: threads may hit it simultaneously, but pass it one by one in a queue with a time gap between them.

Uh, a bottleneck, not a barrier.