• Benjamin Thaut (69/69) Mar 25 2011 First thought:
• Jason House (2/80) Mar 25 2011

Benjamin Thaut <code benjamin-thaut.de> writes:

First thought:
Consider the following code:

import std.concurrency;

class Logger {
	void log(string msg){
		//do logging
	}
}

class ThreadsafeLogger : Logger {
private:
	Tid m_Tid;
public:
	this(){
		m_Tid = thisTid();
	}
	
	/// Returns: tid of owning process
	Tid getTid(){ return m_Tid; }
	
	//this should get called by any thread other then the owner
	void log(string msg) shared {
		send(getTid(),msg);
	}
	
	// this gets called by the owning thread every now and then
	void progressMessages(){
		receiveTimeout(0,
			(string msg){
				//this calles the non shared version
				this.log(msg);
			}
		);
	}
}

The idea behind is to use the functionality of the already implemented 
class for a call from the owning thread and pass messages for any 
threads accessing the functionally from outside of the owning thread 
into the owning thread. Unfortunately D prevents me from implementing it 
like this because it thinks I want to override log, which I cleary not 
want to do, which can be recognized from the shared attribute.
The only solution to solve this is to modifiy the original class, by 
adding a shared log function, which I wanted to prevent.
So would it be usefull to remove this compiler error? Or is there some 
problem connected to this I'm not seeing?

Second thought:

synchronized class main {
private:
	ILogger m_Logger;
	IGame m_Game;
public:
	void work(){
		//do something with m_Logger and m_Game
	}

	ILogger getLogger(){
		return m_Logger;
	}
}

In the above class both m_Logger and m_Game get the shared attribute. 
The shared attribute for the m_Logger variable is ok, because it can be 
queried from the class, and it could be used in other threads.
But the m_Game variable is completely encapsuled into the class and can 
only be used from within the class. As the synchronized prevents any 
paralell use of the class, it should be save to assume that m_Game never 
gets used by multiple threads simulatiously and does not need the shared 
attribute. What do you think about this? Is there some reason to not do 
this I'm not seeing?

-- 
Kind Regards
Benjamin Thaut

Jason House <jason.james.house gmail.com> writes:

Do you require that ThreadsafeLogger is a Logger, or is it ok if
ThreadsafeLogger has a Logger? The latter is trivial to implement.

Benjamin Thaut Wrote:

 First thought:
 Consider the following code:
 
 import std.concurrency;
 
 class Logger {
 	void log(string msg){
 		//do logging
 	}
 }
 
 class ThreadsafeLogger : Logger {
 private:
 	Tid m_Tid;
 public:
 	this(){
 		m_Tid = thisTid();
 	}
 	
 	/// Returns: tid of owning process
 	Tid getTid(){ return m_Tid; }
 	
 	//this should get called by any thread other then the owner
 	void log(string msg) shared {
 		send(getTid(),msg);
 	}
 	
 	// this gets called by the owning thread every now and then
 	void progressMessages(){
 		receiveTimeout(0,
 			(string msg){
 				//this calles the non shared version
 				this.log(msg);
 			}
 		);
 	}
 }
 
 The idea behind is to use the functionality of the already implemented 
 class for a call from the owning thread and pass messages for any 
 threads accessing the functionally from outside of the owning thread 
 into the owning thread. Unfortunately D prevents me from implementing it 
 like this because it thinks I want to override log, which I cleary not 
 want to do, which can be recognized from the shared attribute.
 The only solution to solve this is to modifiy the original class, by 
 adding a shared log function, which I wanted to prevent.
 So would it be usefull to remove this compiler error? Or is there some 
 problem connected to this I'm not seeing?
 
 Second thought:
 
 synchronized class main {
 private:
 	ILogger m_Logger;
 	IGame m_Game;
 public:
 	void work(){
 		//do something with m_Logger and m_Game
 	}
 
 	ILogger getLogger(){
 		return m_Logger;
 	}
 }
 
 In the above class both m_Logger and m_Game get the shared attribute. 
 The shared attribute for the m_Logger variable is ok, because it can be 
 queried from the class, and it could be used in other threads.
 But the m_Game variable is completely encapsuled into the class and can 
 only be used from within the class. As the synchronized prevents any 
 paralell use of the class, it should be save to assume that m_Game never 
 gets used by multiple threads simulatiously and does not need the shared 
 attribute. What do you think about this? Is there some reason to not do 
 this I'm not seeing?
 
 -- 
 Kind Regards
 Benjamin Thaut