Yes, it works as a single threaded program, but there are a lot of code paths that are never taken unless a worker thread finishes a job before the submitter thread needs the result (which obviously can't happen in single-threaded mode).  Therefore, this does not prove that the issue is a concurrency bug.<br>
<br><div class="gmail_quote">On Wed, May 4, 2011 at 1:37 PM, Walter Bright <span dir="ltr"><<a href="mailto:walter@digitalmars.com">walter@digitalmars.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Does it work as a single threaded program?<div class="im"><br>
<br>
On 5/4/2011 6:51 AM, David Simcha wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I went a slightly different route and tried to reduce the problem to as small a test case as possible, like I would normally do for a compiler bug.  So far I've managed to reduce it to ~560 lines.  I've discovered this one's more unstable (i.e. the results change a lot more in response to slight perturbations) than I thought.  Just changing the layout of the Task struct (deleting member variables that are no longer used anywhere) makes it go from unit test failures to access violations. Adding or removing try/catch blocks or empty destructors in some places can completely prevent the bug from manifesting.  On Linux, if I perturb things slightly by changing the layout of Task, I get exceptions thrown from core.sync.<br>

<br>
This looks like some kind of memory/stack corruption bug but due to its nondeterminism (only a few thread interleavings seem to take the proper codepath and I'm not sure which ones) and its very indirect manifestation (memory corruption; the low order bit overwriting thing was, I think, just a manifestation of a deeper problem), I am somewhat at a loss for how to debug it.  I've scrutinized the concurrency related aspects and still can't find any bugs there.  However, I can't prove it's not a concurrency bug since running in single threaded mode prevents certain code paths from being taken.  Unless I get some advice that changes things, I think my next move is to compare the disassemblies for cases that work to those for cases that don't.<br>

<br>
</blockquote></div><div><div></div><div class="h5">
_______________________________________________<br>
phobos mailing list<br>
<a href="mailto:phobos@puremagic.com" target="_blank">phobos@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/mailman/listinfo/phobos</a><br>
</div></div></blockquote></div><br>