www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - queries on druntime

reply Arun Chandrasekaran <aruncxy gmail.com> writes:
Hi,

What are the reasoning behind core.sync.* primitives being 
classes and not structs? This prevents them from being placing on 
shared memory.
Dec 13 2017
next sibling parent Arun Chandrasekaran <aruncxy gmail.com> writes:
On Thursday, 14 December 2017 at 07:04:49 UTC, Arun 
Chandrasekaran wrote:
 Hi,

 What are the reasoning behind core.sync.* primitives being 
 classes and not structs? This prevents them from being placing 
 on shared memory.
s/placing/placed/
Dec 13 2017
prev sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 14 December 2017 at 07:04:49 UTC, Arun 
Chandrasekaran wrote:
 Hi,

 What are the reasoning behind core.sync.* primitives being 
 classes and not structs?
There are several reasons as far as I know: 1) Structs in D can't have non-trivial constructors - i.e. you can't call pthread_mutex_init or InitializeCriticalSection to initialize the underlying OS object. If you go with structs, every call to lock, tryLock and unlock would have to first check if the object has been initialized, and the code would have to guard the initialization from data races. Or alternatively, the code would be unsafe, just like the pthread_* and Win32 APIs. 2) Structs in D best model values, something that doesn't have an identity and could be freely copied around. Yes, you can disable post-blit (with disable `this(this);`) and opAssign, but given the fact that any API that uses them will receive the sync object by reference (e.g. either `Mutex*` or `ref Mutex`) if they were implemented as structs, it would really look better on the API level to simply have reference types. 3) Polymorphism. Third-party libraries like vibe-d have custom synchronization primitives that inherit those in druntime and override their functionality, in vibe-d's case to make them compatible with Fibers. 4) Class monitors currently work through the object.Object.Monitor interface, which core.sync.mutex.Mutex implements.
 This prevents them from being placing on shared memory.
Do you mean shared in the OS sense (mmap with MAP_ANONYMOUS | MAP_SHARED and whatever the Win32 analog is), or in the sense of the D type qualifier, e.g. shared(Mutex)? If you mean shared(Mutex), that should already work since I fixed it a couple of releases ago. I haven't yet had the time to do the work for the rest of core.sync.*, though. If you mean process shared memory, I agree that there are many valid cases where you want to be in control of the memory. I have been thinking about extracting the core of the synchronization primitives into system structs, so users can have more control over them, though I haven't had the time for that either. For now you have two options: A) roll your own struct-based implementations B) manually emplace the class instances on your piece of void[] memory. See https://github.com/dlang/druntime/blob/v2.077.1/src/core/sync/mutex.d#L342 for an example.
Dec 14 2017
parent Arun Chandrasekaran <aruncxy gmail.com> writes:
On Thursday, 14 December 2017 at 08:00:44 UTC, Petar Kirov 
[ZombineDev] wrote:
 If you mean process shared memory, I agree that there are many 
 valid cases where you want to be in control of the memory. I 
 have been thinking about extracting the core of the 
 synchronization primitives into  system structs, so users can 
 have more control over them, though I haven't had the time for 
 that either.

 For now you have two options:
 A) roll your own struct-based implementations
Petar, thanks. I am looking to build an interprocess synchronization primitive. I've tried to do something like this: https://bitbucket.org/carun/boosted/src/tip/source/interprocess/sync/posix/mutex.d But there must be some elegant (idiomatic) way to do this. I get to play with D occasionally, mostly server side high performance stuff. So please feel free to correct my mistakes if any. Are there such common design patterns documented somewhere that can be exploited? (I've watched https://www.youtube.com/watch?v=yMNMV9JlkcQ) - Arun
Jan 02