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