Question about Multi-Threading and Working Together

Game Play & Game Design
#1

Hey guys, I’m pretty far into making a networked top-down shooter but I feel that my code has begun to suffer from crude code done by myself to keep the code working together on different threads. In simple terms, here’s the main concern: I have a thread (clientListener) that receives messages from the server and that will thus have to interpret those messages. I have a main class called Main (clever eh?) that contains the main game loop and the menu system for connecting to the desired server. My problem is that I need to find out on the main thread if the client was accepted by the server which would be on the main thread to figure if it should then prepare the screen for running the game. What is a good way to do so?

Here’s the current code running on the main thread


clientListener.setupForWait(); // Resets the waitingForResponse, acceptedByServer, etc...
statusLabel.setText("Contacting server....");
					
while(clientListener.waitingForResponse) { Thread.yield(); }
					
if(clientListener.acceptedByServer) {
	// Removes all of the connect components
	// Will load map instructed to by server and display that
	this.removeAll();
} else {
	 statusLabel.setText("Rejected from Server: "+clientListener.reason);
}

It works, but it seems ugly. Any suggestions?

#2 

while(clientListener.waitingForResponse) { Thread.yield(); }

This is completely unnecessary in any properly designed threading app. You should block on the response, which will pause the thread until the response is received. The thing that most closely maps to this is a Condition, but those are quite low-level, and judging by the context of the rest of the code around it, is probably an inappropriate primitive to use. You might be better served by using a BlockingQueue of Client objects that the listener enqueues.

Basically, you need to get familiar with the classes in java.util.concurrent and use only those for your concurrency needs.

#3

And blocking infinitely might be slightly bad if you have a slow connection…

#4

My initial reading of the code was that it was for a server accepting connections from clients, which line 2 alone should have told me was wrong… So yeah you probably don’t need a queue, and frankly you don’t need a worker thread at all if all you’re doing anyway is spinning or blocking until connected.

Otherwise, the advice to use java.util.concurrent still stands.

#5

Hey guys thanks for the responses!

Yeah the Thread.yield() was just thrown in becasue I thought it would pause the thread and lower CPU usage but it sounds like that wouldn’t be a good idea :slight_smile:

Currently looking at concurrent threads. I’ll update this and post back on how I restructure things.

#6

yield say: If there is another thread of equal or higher priority than me in my process wanting to run, then let them, otherwise I want to maintain control. So it’ll never lower CPU usage. sleep(0) says stop me and put me back into the scheduler right now.

#7

Depending on the OS, yield==sleep(0)

IIRC this is the case for Windows - keep in mind that the behaviour is different since Windows Server 2003.

#8

On Windows it’s Sleep(0), on Linux it’s sched_yield. Not sure why they didn’t use SwitchToThread on windows, but judging by the docs for SwitchToThread, it looks to have the same effect, namely that the thread loses the rest of its timeslice. Regardless of the implementation, a loop that does nothing but yield will chew up far more CPU due to context switches than one that blocks on a condition instead. You simply shouldn’t see Thread.yield() in most code you run across.