Singleton template using its methods in different threads

When developing a singleton class that can be used by multiple threads, I come across the following task:

This leaves the main thread and another thread called the client. The main method first gets an instance, and then clients also get instances. And then the client executes the singleton class method, my debug step shows that the main thread is interrupted to execute the method that the client calls.

How can I guarantee that the client thread executes this method without interrupting the main thread.

Thanks in advance for your efforts.

Cheers Bob

Edit:

public class SingletonEsperEngine { private static SingletonEsperEngine esperEngineObject; //Configuration for the Esper Engine private static Configuration cepConfig; //EPSServiceProvider represents the engine instance private static EPServiceProvider cep; private static EPRuntime cepRT; private static EPAdministrator cepAdm; private static boolean IsAlreadyInitialized; private static boolean IsNodeIdAvailable; public static ArrayList<EPStatement> cepStatement; public static ArrayList<EPStatement> cepLogInfo; public static ArrayList<EPStatement> cepFilterStatement; public static HashMap<String, Integer> mStatistics; public static HashMap<Integer, Integer> mNodeIds; //Experiment instantions private static JoinDebug joinDebugExperiment; private SingletonEsperEngine() { } /** * In order to prevent simultaneous invocation of the getter method * by 2 threads or more, we add the synchronized keyword to the method * declaration. * * @return SingletonEsperEngine */ public static synchronized SingletonEsperEngine getInstance() { if (esperEngineObject == null) { esperEngineObject = new SingletonEsperEngine(); IsAlreadyInitialized = false; IsNodeIdAvailable = false; } return esperEngineObject; } /** * InitEsperService * * Initialize the Esper Engine to accept MyriaNed messages. * * @return */ public static synchronized int InitEsperService() { } public int dataToEsperEngine(String data, int numOfClient) { //Split string into timestamp and Myrianed Message 32 bytes String strTimestampClientSec = data.substring(0, 16); String strTimestampClientNano = data.substring(16, 32); String strTimestampSniffer = data.substring(32, 40); String message = data.substring(40); String joinBitMask = CONSTANT.JOIN_MESSAGE_bm.substring(2, 4) + CONSTANT.JOIN_MESSAGE_bm.substring(0, 2); HashMap<String, Object> Event = new HashMap<String, Object>(); //It is an join message Event = putDataIntoEvent(message, evaluationMsgStruct, stamp, numOfClient); cepRT.sendEvent(Event, CONSTANT.JOIN_MESSAGE) if (CONSTANT.DEBUG) { printEventHashMap(Event, evaluationMsgStruct); } return CONSTANT.SUCCESS; } 

The problem occurs when a client thread calls dataToEsperEngine()

 public class Client implements Runnable { Socket mClientConnectionSocket; Connection mCon; //Seperate thread for every client, to handle the communication and event processing //ClientThread clientThread; public static Boolean stopClientThreads = false; public int mMode = CONSTANT.CLIENT_MODE_IDLE; public int mNumberOfThisClient; SingletonEsperEngine mEsperSupport; public Thread t; private String name; public void run() { String tmp = null; int idleTime = CONSTANT.SHORT_IDLE_TIME; while (!stopClientThreads) { try { tmp = null; switch (mMode) { case CONSTANT.CLIENT_MODE_STOP: //This will cause exiting of the while loop and terminates the thread stopClientThreads = true; return; case CONSTANT.CLIENT_MODE_IDLE: //Being lazy break; case CONSTANT.CLIENT_MODE_RECEIVE_STREAM: tmp = receiveMessage(); if (tmp != null) { System.out.println(tmp); mEsperSupport.dataToEsperEngine(tmp, mNumberOfThisClient); } break; } //I am aware of the performance issues //TODO rebuild with execution pool this.t.sleep(idleTime); } catch (InterruptedException ex) { Logger.getLogger(Client.class.getName()).log(Level.SEVERE, null, ex); } } return; } Client(Socket cC, String name) { //Save socket (=connection) into the client class mClientConnectionSocket = cC; gui.Debug.logThis("The server made a connection with: " + mClientConnectionSocket.getInetAddress()); mEsperSupport = mEsperSupport.getInstance(); this.name = name; mMode = CONSTANT.CLIENT_MODE_IDLE; t = new Thread(this); t.start(); this.mNumberOfThisClient = Integer.parseInt(name); //Connect the input and output stream try { mCon = new Connection(new BufferedReader(new InputStreamReader(mClientConnectionSocket.getInputStream())), new PrintWriter(mClientConnectionSocket.getOutputStream())); } catch (IOException ex) { Logger.getLogger(Client.class.getName()).log(Level.SEVERE, null, ex); } } public String receiveMessage() { String tmp = null; try { tmp = mCon.cFrom.readLine(); } catch (IOException ex) { Logger.getLogger(Client.class.getName()).log(Level.SEVERE, null, ex); } return tmp; } } 
+4
source share
3 answers

This has nothing to do with singles, right? You should synchronize methods that should not be interrupted, possibly using the synchronized . This is a tricky question to answer in full, there are several books (such as Doug Lea parallel programming in Java) that you can advise. In addition, your question is not formulated accurately enough for me to add more details.

+6
source

Then the client executes the method of the singleton class, my debugging step through shows me that the main thread is interrupted to execute the method that is called by the client.

This is absolutely impossible (if only your main thread and singleton class contain quite complex code to force tham to do this, in which case the solution, of course, will not implement them that way). Most likely you are misinterpreting what the debugger displays.

+2
source

It is possible, but you only perform synchronization on “critical sections”, “critical data”. Since I have not seen a critical section in your code, I do not think you really need synchronization between the client and the main thread. Perhaps this line can be considered as a critical section:

 Event = putDataIntoEvent(message, evaluationMsgStruct, stamp, numOfClient); 

But with the source you gave, it's hard to say.

0
source

All Articles