www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Shared with synchronized

reply r-const-dev <r.const.dev gmail.com> writes:
I'm trying to implement a thread safe class, guarding data access 
with synchronized and atomicOp.

Inside the class I'm using non-shared fields, such as Nullable, 
but I guarantee the thread safety using synchronized. How can I 
tell the compiler to allow using non-shared fields/methods inside 
synchronized?

Here is my example:

import core.atomic : atomicOp;
import std.typecons : Nullable;

class SharedObject {
     private Object lock = new Object();
     private Nullable!int sharedValue;
     private int changeCount = 0;
     synchronized void modifyValue(int newValue) {
       	sharedValue = newValue;
        	atomicOp!("+=")(changeCount, 1);
     }
}

void main()
{
     shared SharedObject data = new shared SharedObject();
     data.modifyValue(3);
}

I get the error:
onlineapp.d(9): Error: template 
std.typecons.Nullable!int.Nullable.opAssign cannot deduce 
function from argument types !()(int) shared, candidates are:
/dlang/dmd/linux/bin64/../../src/phobos/std/typecons.d(2884):     
    std.typecons.Nullable!int.Nullable.opAssign()(T value)
Mar 03
parent reply r-const-dev <r.const.dev gmail.com> writes:
On Sunday, 3 March 2019 at 22:35:54 UTC, r-const-dev wrote:
 I'm trying to implement a thread safe class, guarding data 
 access with synchronized and atomicOp.

 Inside the class I'm using non-shared fields, such as Nullable, 
 but I guarantee the thread safety using synchronized. How can I 
 tell the compiler to allow using non-shared fields/methods 
 inside synchronized?

 Here is my example:

 import core.atomic : atomicOp;
 import std.typecons : Nullable;

 class SharedObject {
     private Object lock = new Object();
     private Nullable!int sharedValue;
     private int changeCount = 0;
     synchronized void modifyValue(int newValue) {
       	sharedValue = newValue;
        	atomicOp!("+=")(changeCount, 1);
     }
 }

 void main()
 {
     shared SharedObject data = new shared SharedObject();
     data.modifyValue(3);
 }

 I get the error:
 onlineapp.d(9): Error: template 
 std.typecons.Nullable!int.Nullable.opAssign cannot deduce 
 function from argument types !()(int) shared, candidates are:
 /dlang/dmd/linux/bin64/../../src/phobos/std/typecons.d(2884):
    std.typecons.Nullable!int.Nullable.opAssign()(T value)
Found a solution, hope it is a recommended one: cast `this` to non-shared and invoke an "unsafe" method. Inside everything is allowed: import std.typecons : Nullable; class SharedObject { private Nullable!int sharedValue; private int changeCount = 0; synchronized void modifyValue(int newValue) { (cast(SharedObject)this).unsafeModifyValue(newValue); } private void unsafeModifyValue(int newValue) { sharedValue = newValue; ++changeCount; } } void main() { shared SharedObject data = new shared SharedObject(); data.modifyValue(3); }
Mar 03
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, March 3, 2019 5:07:39 PM MST r-const-dev via Digitalmars-d-learn 
wrote:
 On Sunday, 3 March 2019 at 22:35:54 UTC, r-const-dev wrote:
 I'm trying to implement a thread safe class, guarding data
 access with synchronized and atomicOp.

 Inside the class I'm using non-shared fields, such as Nullable,
 but I guarantee the thread safety using synchronized. How can I
 tell the compiler to allow using non-shared fields/methods
 inside synchronized?
 Found a solution, hope it is a recommended one: cast `this` to
 non-shared and invoke an "unsafe" method. Inside everything is
 allowed:
That's basically what you have to do. shared makes most operations which are not atomic illegal (it really should make them _all_ illegal, but it doesn't currently), thereby protecting you from bugs related threading isssues. So, what you then typically need to do is protect the shared variable with a mutex and then cast away shared while the mutex is locked so that you can operate on the object as thread-local. It's then up to the programmer to ensure that no thread-local references to the shared object escape. So, when the mutex is released, all of the thread-local references should be gone. It can be a bit annoying, but it means that your code in general is protected from threading bugs, and the code that has to actually deal with the threading issues is segregated (similar to how safe code doesn't have to worry about memory issues, and trusted is then used to allow system stuff to be done from safe code, thereby segregating the code that needs to be verified for memory issues). - Jonathan M Davis
Mar 04