digitalmars.D.learn - Weird multithreading stuff
I'm writing a program to parse and evaluate mathematical
expressions
the parse tree is in the format:
struct node
{
string token;
node*[] children;
}
it is parsed such that for the input 1*(2+3)-4*(5+6), the tree
ends up looking like
-
* *
1 + 4 +
2 3 5 6
When the time comes to evaluate this I thought a sensible way to
do it would be this
real evaluate(node top)
{
real output;
string token = top.token;
if (tokenIsAnOperator)
{
real[2] operands;
foreach (i, child; parallel(top.children))
{
operands[i] = evaluate(*child);
}
output = someFunctionWiththeRightOperator(operands[0],
operands[1]);
}
else // it must be a number
{
output = parse!real();
}
return output;
}
Which works perfectly - about 20-30% of the time
I can literally paste 1*(2+3)-4*(5+6) into the input over and
over, and I get
0
5
-39
no digits seen
Floating point conversion error for input "".
seemingly randomly (those two errors are apparently coming from
somewhere in the std library)
When I put in less complicated expressions I get the right answer
more of the time, but it can still come out wrong occasionally
And the weirdest part: when I remove "parallel" from the foreach
loop, it always gives me the correct answer
anyone know what's going on here, and/or how to fix it?
Jan 29 2016
Okay it somehow just got even stranger that condition 'tokenIsAnOperator' in that code is a function to test whether the token is contained within the array ["+", "-", "*", "/"] It seems that sometimes it returns true for "*", and sometimes false, but only when I have "parallel" in that foreach loop what?
Jan 29 2016
Okay so it turns out putting something in another thread is like throwing it into an alternate universe where only my functions exist, and instead of telling me my data doesn't exist, it just silently behaves as if it's all empty Man, threads are weird. I'll just pass the data in as an argument or something christ
Jan 29 2016
On Saturday, 30 January 2016 at 05:15:58 UTC, asdf wrote:Okay so it turns out putting something in another thread is like throwing it into an alternate universe where only my functions exist, and instead of telling me my data doesn't exist, it just silently behaves as if it's all emptyAre you aware that variables declared "static" or at global scope in D are actually thread-local by default? Anyway, you can't really expect anyone else to be able to debug something like this with just pseudo-code. Give me a *complete* program which you think should work on GitHub or http://dpaste.dzfl.pl/ and I'll see what I can do with it. Since your problem occurs at runtime, make sure that it actually compiles without error before you post it.
Jan 29 2016
On Saturday, 30 January 2016 at 05:41:10 UTC, tsbockman wrote:On Saturday, 30 January 2016 at 05:15:58 UTC, asdf wrote:No I've fixed it now All I was asking for anyway was a little bit of help as to how threads work, which "variables declared "static" or at global scope in D are actually thread-local by default" definitely satisfies. I wasn't really asking for someone to read through and debug my entire program ThanksOkay so it turns out putting something in another thread is like throwing it into an alternate universe where only my functions exist, and instead of telling me my data doesn't exist, it just silently behaves as if it's all emptyAre you aware that variables declared "static" or at global scope in D are actually thread-local by default? Anyway, you can't really expect anyone else to be able to debug something like this with just pseudo-code. Give me a *complete* program which you think should work on GitHub or http://dpaste.dzfl.pl/ and I'll see what I can do with it. Since your problem occurs at runtime, make sure that it actually compiles without error before you post it.
Jan 29 2016
tsbockman <thomas.bockman gmail.com> On Saturday, 30 January 2016 at 05:57:20 UTC, asdf wrote:No I've fixed it now All I was asking for anyway was a little bit of help as to how threads work, which "variables declared "static" or at global scope in D are actually thread-local by default" definitely satisfies. I wasn't really asking for someone to read through and debug my entire program ThanksIt's rarely necessary to provide the entire *original* program. But, you're a lot more likely to get real help if you include a simple program that demonstrates the problem (a "reduced test case"), which other people can try out. As an example of why this is important, consider that the true source of your problem cannot actually be found in the code you posted above, at all. I guessed what it was, based on your follow-up post - but that's all I was doing: *guessing*. It could have turned out to be something else entirely - maybe even a bug in the compiler or the standard library. (These are still rather common with D, unfortunately.) I think you'll also find, in general, that producing a good, simple test case is a very effective technique for debugging your own code - even before you ask others for help.
Jan 29 2016