Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  NIO and wait share interrupt flag >:(  (Read 909 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Posted 2005-04-17 09:43:18 »

In a way, I can't believe it's taken me this long to realise the horror of this setup, but I've just been bitten by it for the first time:

  NIO and Object.wait() share the same messaging primitive, so you can only use one or the other, not both...

Thinking about it now, I'm lost for words: I must be missing something obvious, because it's insanely stupid otherwise.

To make NIO work properly, you need to interrupt your threads, since Sun (in their infinite wisdom) decided to allow NIO to block indefinitely if you chose to touch the selector (IIRC there's no particular reason for this, other than that it made it easier for them to implement their own API).

But that means you cannot use wait/notify anywhere in your select'ing thread, because the JVM has no means to distinguish between "interrupt any blocked NIO" and "interrupt any blocked monitor". And I've just tried using a select'ing thread that, deep down in other code many classes away, performs a wait() for a brief period.

(yes, I know I shouldn't, and I will convert it to not using wait eventually and being purely asynch, but there was no reason why wait shouldn't work that I could see at the time and it would save me significant implementation time for now, at the cost of some performance at runtime).

I'm now sitting here wondering if I can think up a hack to workaround this that doesn't have some obscure synchronization bug in it Sad.

...or if the GrexEngine selectors need to be rewritten not to ever ever interrupt (which I don't think is possible) or to do extra checks before interrupting using some internal hack to make up for the fact that Sun shared the blocking flag between two totally unrelated systems Sad.

Any ideas would be welcome at this point, especially if someone spots an obvious mistake I'm making

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #1 - Posted 2005-04-17 09:46:43 »

PS: I can see one obvious way out: getting the GrexEngine core rewritten so that it uses select(long) everywhere is *a* solution but practically useless (and not something that would be worth doing to the GE I suspect) ... in order to make services responsive, that long would have to be around 1 ms, or much less, so effectively you wouldn't have a selector at all but a highly inefficient poller.

malloc will be first against the wall when the revolution comes...
Offline kevglass

JGO Kernel


Medals: 186
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #2 - Posted 2005-04-17 09:48:50 »

To me, sounds like misuse of the interrupting really. If you're interrupting a thread its because you know its waiting in a state that is now invalidated because of some other event.

If you're not sure what state its in how come you're interrupting it?

Hmm.. maybe I've just only ever had naive use for it in the past.

Kev

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #3 - Posted 2005-04-17 10:01:34 »

Ah! Found it Smiley. Selector.wakeup (maybe...haven't checked fully yet)

But ... now I need to go and find *why* the GE base-service I'm using doesn't use it, but instead uses interrupt Huh. Perhaps...wakeup didn't work on all platforms at some point, and this is a legacy workaround?

/me needs to get hold of the design notes for the GE internals and check...

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #4 - Posted 2005-04-17 10:11:54 »

/me has been very stupid

The GE I/O code all uses wakeup, as you would expect.

But... the base service I'm extending is a threaded class that accepts workloads asynchronously (nothing to do with NIO). It's such a basic class that I had been extending without even bothering to look at it carefully Embarrassed

It needs to idle whilst there's no work to do, and the base class has a sleep( 10 seconds ), whilst the work-accepting method does an interrupt each time new work comes in.

This should, AFAICS, be a wait-on-incoming-queue and notify-when-queue-added-to. The fact that it's interrupting instead of using wait/notify as you'd expect is what then caused pain later on, and caused this mess.

/me goes off to check if there's a particular reason it isn't wait/notifying...

malloc will be first against the wall when the revolution comes...
Offline Jeff

JGO Coder




Got any cats?


« Reply #5 - Posted 2005-04-18 03:56:52 »

YUp.

Thats just BAD Java code.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (49 views)
2014-10-17 03:59:02

Norakomi (38 views)
2014-10-16 15:22:06

Norakomi (31 views)
2014-10-16 15:20:20

lcass (35 views)
2014-10-15 16:18:58

TehJavaDev (65 views)
2014-10-14 00:39:48

TehJavaDev (65 views)
2014-10-14 00:35:47

TehJavaDev (55 views)
2014-10-14 00:32:37

BurntPizza (72 views)
2014-10-11 23:24:42

BurntPizza (43 views)
2014-10-11 23:10:45

BurntPizza (84 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!