[Issue 8774] 2.059 worked 2.060 does not: Unable to join thread
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Tue Dec 25 06:14:17 PST 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8774
--- Comment #15 from Dmitry Olshansky <dmitry.olsh at gmail.com> 2012-12-25 06:14:16 PST ---
(In reply to comment #13)
>
> Yes, you are correct, it does not make much sense, but there is another issue.
> The following code throws an exception on 64-bit linux (32-bit linux and 32-bit
> windows executes without throwing an exception). On 64-bit linux t2 is never
> started.
>
How did you get to this conclusion?
> -----
>
> module program;
>
> import std.stdio;
> import core.thread;
>
> void main () {
>
> Thread t1, t2;
> bool runned = false;
>
> t1 = new Thread(delegate { t2.start(); });
> t2 = new Thread(delegate { runned = true; });
>
> t1.start();
> Thread.sleep(dur!"seconds"(1));
> assert(runned);
>
> }
>
> -----
>
> http://dpaste.dzfl.pl/5dc9733e
>
>
> Should I file a new bug report ?
And again there is no guarantee that:
a) access to runned is properly guarded and made visible in all threads as it's
on stack and not declared as shared nor there are memory barriers. TEchnically
compiler is free to do what the heck it wants to.
b) sleep is not a tool to coordinate threads, use locks and condition variables
(or spin on atomic variables) as there is *always* a *chance* to get to
assert(runned) before t2 is executed.
With all that being said it very well *may* be a bug. Yet the test is still
bogus. Again until proper synchronization is enacted it's wrong to conclude
*anything* aside from the fact that it's ultimately indeterministic.
So if you'd get this in a form where there are no probabilities involved then
sure it's a bug and the report is appreciated.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
More information about the Digitalmars-d-bugs
mailing list