game freezes when dealing with selector

Newbie & Debugging Questions
#1

Hello.
I don’t know what to do anymore so I’m hoping this happened before and someone knows the solution.

I noticed that my game client freezes about every 10th time it connects to server. I’m calling connect method directly from main menu in main thread so when this occurs repaints don’t work and minimize / restore gives emtpy gray screen. I must stop the jvm to shutdown the game. Soon I discovered on what line thing freezes… when connecting to server it uses SocketChannel.open(IP), sets blocking on channel to false, and finally registers for OP_READ. Game froze on:

s_channel.register(selector, SelectionKey.OP_READ);

… I was thiniking maybe it’s some synchronization problem since I have main menu thread, animation thread, server thread and packet sender thread. Allthough they didn’t touch much, especially here, I deceided to synchronize it on selector:

System.out.println("BBBBBBBBBBBBB");
    synchronized (selector) {
        System.out.println("CCCCCCCCCCCC");
	try {
            s_channel.register(selector, SelectionKey.OP_READ);
            System.out.println("DDDDDDDDDD");
    ...........................and so on............................

On my suprise the thing kept freezing as before, but the suprising part is that now it froze on

synchronized (selector) {

line! Like wtf!? The B’s are printed out, but the C’s are not… I’m feeling really dumb now, could this be something completely different? Why would it freeze on java keyword? Only thing in common in both freezes is selector reference.
Anyway I’m hoping I’m assuming it wrong and then it could be something else since I don’t know how to fix this. Any similar experience? Any suggestions on ways how to debug this? Thank you.

Edit: forgot to explicitly mention, it does not throw an exception or native error, it just freezes in a way you can minimize / maximize it (gray screen) but all other things like clicks and others are gone as I can see.

#2

When you select() you synchronize on the object. Appearantly the register(…) method also synchronizes on the same lock, so you can only register (without waiting for a lock) when the lock is released by for example the select() method returned (processing I/O) or registering from inside the select-loop (which is basicly the same).

The fact that you see a ‘freeze’ on “synchronized( selector )” confirms this, and I kinda wonder why you are so stunned by that, as the behaviour of the synchronization keyword is the basics of multi-threaded synchonisation.

In short, you’re trying to register(), which waits for a lock that is kept by another thread by blocking on select()

#3

Do it without using threads. Part of the point of NIO is asynchronous networking. So you can run your network code in the main thread and it won’t block. This way you don’t have to deal with errors that can be hard to find in threaded environments.

#4

Ah… that makes more sense… tnx Riven. I’ve read O’Reilly Java NIO 2 times (second time not so long ago while I was fixing this kind of bugs, this is my last one :slight_smile: ), it dosen’t have anything about select() locking selector or I missed / ignored it. Actually I’m not so suprised as it uses lock on selector now, but I was suprised it worked in 90% of time so I didn’t bother to think of it that way. If it won’t work at all (as expected with this) then I would find it.
So I guess solution would be to queue request for connect in same thread or do it before select() comes into action (or call wakeup() … but that seems messy).

CaptainJester… it’s kind of really hard and non OOP to do it all in one thread… have you tried it? Networking is obviusly extreamly slower then cpu so it could stall my app. frequently. Also it would be messy and hard to make since I would have to have game loop (animation), receiving data (selectNow() ), sending data every x ms and such in one thread. All that would have to go in game loop and that would be pretty confusing as I think of it. If someone has done it this way and it’s good I would like to see it :slight_smile:

#5

If that were true, I’d say you should bin the book, cos that’s one of the most important things a book on NIO would have to talk about :(. IIRC it’s a generally OK book, so I’m sure it does in fact explain this at some point :smiley:

#6

I’ve checked to be sure, it does mention it but it’s not within basics or using selectors, but in concurrency (kind of expected it in basics, so even If I read it I didn’t payed so much attention to this I guess).
Anyway O’Reilly’s Java NIO is a great book, I recommend it to anyone who wish to learn NIO.