www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - D Mutex reference.

reply "Saaa" <empty needmail.com> writes:
Where is it? 
Jan 18 2007
parent reply Alexander Panek <a.panek brainsware.org> writes:
Saaa wrote:
 Where is it? 
 
 
http://digitalmars.com/d/statement.html#SynchronizedStatement Does this one help?
Jan 18 2007
parent reply "Saaa" <empty needmail.com> writes:
 http://digitalmars.com/d/statement.html#SynchronizedStatement

 Does this one help?
Thanks for the reply. I have one thread generating alot of data and main reading a few of them every 10ms or so. This can be a problem, right? (when main tries to read some data which hasn't been writting completely?) Reading about multi threading pointed me to mutexes, but I can't find any reference. Synchronized only locks a part of the code, not the actual data?
Jan 18 2007
parent reply Alexander Panek <a.panek brainsware.org> writes:
Saaa wrote:
 http://digitalmars.com/d/statement.html#SynchronizedStatement

 Does this one help?
Thanks for the reply. I have one thread generating alot of data and main reading a few of them every 10ms or so. This can be a problem, right? (when main tries to read some data which hasn't been writting completely?)
Actually, yes.
 Reading about multi threading pointed me to mutexes, but I can't find any 
 reference.
 Synchronized only locks a part of the code, not the actual data? 
The point of synchronized blocks is, that you can finish what ever you do with your data, without getting interrupted by another thread. There are two ways to use synchronized: a) standalone, so it's like Windows' critical sections: synchronized { /* ... code ... */ } b) synchronized with an object "synchronized (Expression), where Expression evaluates to an Object reference, allows only one thread at a time to use that Object to execute the ScopeStatement. If Expression is an instance of an Interface, it is cast to an Object." synchronized ( /* expression or object */ ) { /* ... code ... */ } Apparently, b) should be the way to go for you. Best regards, Alex
Jan 18 2007
parent reply "Saaa" <empty needmail.com> writes:
I'm not really doing OOP, or am I reading it incorrectly again?
What is the object reference?
I just use a simple (never-ending)  function for the data generation.
Should I just encapsulate this function in synchronize?
Thanks, Saaa

 http://digitalmars.com/d/statement.html#SynchronizedStatement

 Does this one help?
Thanks for the reply. I have one thread generating alot of data and main reading a few of them every 10ms or so. This can be a problem, right? (when main tries to read some data which hasn't been writting completely?)
Actually, yes.
 Reading about multi threading pointed me to mutexes, but I can't find any 
 reference.
 Synchronized only locks a part of the code, not the actual data?
The point of synchronized blocks is, that you can finish what ever you do with your data, without getting interrupted by another thread. There are two ways to use synchronized: a) standalone, so it's like Windows' critical sections: synchronized { /* ... code ... */ } b) synchronized with an object "synchronized (Expression), where Expression evaluates to an Object reference, allows only one thread at a time to use that Object to execute the ScopeStatement. If Expression is an instance of an Interface, it is cast to an Object." synchronized ( /* expression or object */ ) { /* ... code ... */ } Apparently, b) should be the way to go for you. Best regards, Alex
Jan 19 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Saaa wrote:
 I'm not really doing OOP, or am I reading it incorrectly again?
 What is the object reference?
 I just use a simple (never-ending)  function for the data generation.
 Should I just encapsulate this function in synchronize?
You could always allocate an object just for this purpose. Something like this: ----- Object lock; static this() { lock = new Object; } void foo() { synchronized(lock) { // ... } } void bar() { synchronized(lock) { // ... } } -----
Jan 19 2007
parent reply Saaa <yourbase to.us> writes:
Doesn't D have mutexes?
Or better: What is the advantage of synchronized over the use of mutexes?

Could you explain this line:
static this() {
lock=new Object;
}
Does this mean I need to enable the GC?(I mean, not disable it :)
Jan 19 2007
next sibling parent Alexander Panek <a.panek brainsware.org> writes:
Saaa wrote:
 Doesn't D have mutexes?
 Or better: What is the advantage of synchronized over the use of mutexes?
 
 Could you explain this line:
 static this() {
 lock=new Object;
 }
 Does this mean I need to enable the GC?(I mean, not disable it :)
If I understood that correct, a synchronized object actually /is/ a mutex.
Jan 19 2007
prev sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Saaa wrote:
 Doesn't D have mutexes?
 Or better: What is the advantage of synchronized over the use of mutexes?
Every object has an associated mutex. (technically it's created on first use of that object in a "synchronized(obj) {}" statement)
 Could you explain this line:
 static this() {
 lock=new Object;
 }
This initializes the lock variable at the start of the program. IIRC you can't new an object in the initializer of a static function, so this is how you do it.
 Does this mean I need to enable the GC?(I mean, not disable it :)
Disabling the GC only disables the actual collection, not the allocation of objects. Since it's in a global variable (in the example) it will never need to be collected. If you only need a mutex temporarily you can create an Object, make a reference to it available to the various threads that need it, and delete it when you're done with it. No GC required.
Jan 19 2007