Comments on Programming and Debugging (in my Underhøøsen): Nested Functions and Delegates

BCS,I spent more time thinking about the problem t...

2009-02-16T10:13:00.000-08:00

BCS,

I spent more time thinking about the problem that you outlined.

Over the weekend I had an email exchange with Walter and Bartosz on the topic of threads behavior.
It turns out that in D 2.0 when a thread is constructed from a delegate, that delegate must have a "shared" modifier (but the specifics of thread creation are not fully baked yet).

I am thinking about using the "shared" hint and construct the nested function's context in a way that avoids the problem that you so diligently identified. I will post an update when I have a working solution.

Thank you for your insight.Your observation is acc...

2009-02-12T16:03:00.000-08:00

Thank you for your insight.

Your observation is accurate, the delegate (or any nested function for that matter) will not affect the outer scope until the call returns. That's when "the transaction commits".

But I do not see it as incorrect behavior, because I am not aware of any official D specification that governs the observable behavior of multi-threaded programs.

Implementation-dependent behavior is legal (albeit not necessarily fair) game.

I agree a hundred percent that in the case that you described a better design would be for shared data to reside in an object.

I would never risk having a thread accessing the local variables of some function, betting that it's activation record is valid in another thread (with or without reference counting).

there are several problems with what you describe ...

2009-02-12T15:32:00.000-08:00

there are several problems with what you describe (assuming I don't understand incorrectly). It sounds like a delegate will not effect the outer function's variable until after it returns to the outer function. what happens in the case that a delegate is called by a called thread or if it is called from another thread. As a pathological case: A thread is launched that calls a delegate that alters a flag in the outer function and then waits for another flag there to be changed. The outer function continues in the old thread an waits on the first flag an then sets the second. Under DMD this would work, but not under your implementation.

I think the correct way to make this work would be to have all variables referred to by nested function only reside in an object. All accesses, by the outer function or nested functions use this object.