www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Lock Options in D article in Dr. Dobb's

reply Walter Bright <newshound1 digitalmars.com> writes:
Bartosz Milewski has just published "Lock Options" in the January Dr. 
Dobb's.

http://www.ddj.com/cpp/212201754

He provides a D implementation of it.
Dec 12 2008
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Walter Bright wrote:
 Bartosz Milewski has just published "Lock Options" in the January Dr. 
 Dobb's.
 
 http://www.ddj.com/cpp/212201754
 
 He provides a D implementation of it.

Now on reddit: http://www.reddit.com/r/programming/comments/7j7gc/lock_options_a_compiletime_deadlock_prevention/
Dec 12 2008
prev sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Walter Bright wrote:
 Bartosz Milewski has just published "Lock Options" in the January Dr. 
 Dobb's.
 
 http://www.ddj.com/cpp/212201754
 
 He provides a D implementation of it.

Unfortunately, I'm pretty sure it's buggy :(. In his final implementation he uses a mixin to create a declaration for a scope variable (the lock). That variable will be destroyed before the end of the mixin, not before the end of the containing scope (statement mixins create an implicit scope). See for yourself: ----- module test; import tango.io.Console; class Verbose { this() { Cout("Constructed").newline(); } ~this() { Cout("Destructed").newline(); } } void main() { Cout("Start of main").newline(); mixin("scope lock = new Verbose;"); Cout("End of main").newline(); } ----- Output: ===== Start of main Constructed Destructed End of main ===== It should work without that mixin, but it won't be nearly as nice-looking.
Dec 13 2008
parent "Nick Sabalausky" <a a.a> writes:
"Frits van Bommel" <fvbommel REMwOVExCAPSs.nl> wrote in message 
news:gi06f7$274a$1 digitalmars.com...
 Walter Bright wrote:
 Bartosz Milewski has just published "Lock Options" in the January Dr. 
 Dobb's.

 http://www.ddj.com/cpp/212201754

 He provides a D implementation of it.

Unfortunately, I'm pretty sure it's buggy :(. In his final implementation he uses a mixin to create a declaration for a scope variable (the lock). That variable will be destroyed before the end of the mixin, not before the end of the containing scope (statement mixins create an implicit scope). See for yourself: ----- module test; import tango.io.Console; class Verbose { this() { Cout("Constructed").newline(); } ~this() { Cout("Destructed").newline(); } } void main() { Cout("Start of main").newline(); mixin("scope lock = new Verbose;"); Cout("End of main").newline(); } ----- Output: ===== Start of main Constructed Destructed End of main ===== It should work without that mixin, but it won't be nearly as nice-looking.

That explains a certain mystery I encountered in a library I wrote. Everything *seemed* like it should have worked with "scope" instead of "auto" but it never did. The variables that were mysteriously unconvertable to "scope" were declared in a mixin. This makes me wonder though: should mixins be implicitly creating a new scope at all? Clearly there are cases where it's desireable to not have that implicit scope, and with the current behavior I don't see a workaround. Are there cases where an implicit new scope would be desired? If so, could those cases be sufficiently worked around by explicitly creating a new scope in the mixin?
Dec 13 2008