wood burning stoves*
The moose likes Threads and Synchronization and the fly likes reader interface, wait() then go Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "reader interface, wait() then go" Watch "reader interface, wait() then go" New topic
Author

reader interface, wait() then go

Zaeed McColin
Ranch Hand

Joined: Jan 13, 2009
Posts: 90
hi guys, unfortunately I'm not expert in threads, specially synchronizing.
alright, there is a method "boolean ready()" which returns true when the reader object is ready for reading the stream. we have to wait till this guy return true. now I've completely become crazy. please help. how to use synchronize block and wait and notify?
here is a syntax guy.

thanks.


Open source
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19680
    
  18

Arash, on your keyboard there is a button, just above the right shift. It's called "Enter". Use it

Here's your code with some enters added. Just look how much easier it is to read:


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Jim Hoglund
Ranch Hand

Joined: Jan 09, 2008
Posts: 525
Thanks Rob. How is bb.ready set true/false by other thread(s)?
A common approach is to reset it here, all synchronized. What
behaviors are you seeing now? Jim ... ...

BEE MBA PMP SCJP-6
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18760
    
  40

The purpose of the ready() method is to determine whether data is available without blocking. The reason it is provided, is to allow the read() method to be called without the concern of blocking.

Now... you want to cause your application to wait for the data to be available, so that you can get true when you call the ready() method -- of which, then you will call the read() method. Why can't you just skip all the waiting stuff, and also skip the call to the ready() method too, and call the read() method directly? Doesn't calling the read() method, and letting it block, serve the same purpose?

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Zaeed McColin
Ranch Hand

Joined: Jan 13, 2009
Posts: 90
Many thanks Rob, sorry men I have problem with pressing enter . so sorry. and thanks for pure, clean, cool formatted syntax. Jim as Henry mentioned this method returns true when the incoming stream is ready and isn't blocked by other side(client), I've tried to skip the ready method(as Henry said) and read the data directly but in many times stream missed because application returns -1 when call read(). well each incoming stream are parsed in a separated thread, now in each thread, I have to wait till ready() guy returns true. thanks friends again. bty Jim Reader is a abstract method and I don't have its life cycle. Thanks.
Jim Hoglund
Ranch Hand

Joined: Jan 09, 2008
Posts: 525
Arash M. Dehghani wrote:...many times stream missed because application returns -1
when call read(). well each incoming stream are parsed in a separated thread...

How is it that you are missing data when -1 means the stream has ended and why are you using
multiple threads? Are the data combined in some way? I think Henry is on the right track.

Jim ... ...
Zaeed McColin
Ranch Hand

Joined: Jan 13, 2009
Posts: 90
well let's face it again. it should be multiple thread. this is kinda socket programing which clients send request to the server via HTTP1.x and a customized protocol, so it should be multi thread of course. this guy have to support many clients in a same time(imagine a HTTP server), the problem is Reader returns -1 when end of the incoming stream reached or the stream is not ready for read, well as the second part stream will be missed. it's terrible.
at the first application (server) gets the request (socket object) then parse it in a separated thread and waits for next one. the created thread starts to parse the socket object (incoming stream) but before it goes for it, should check the ready state of Reader (stream).
here another syntax may help.

the [D part]: application hangs (waits) on this statement, but sometimes (very cool situation) application skip it because before VM runs this statement Reader is ready for read. as I said I'm terrible in synchronizing. I don't know which object should be being monitored and how to use wait() and notify().
Thanks again.
Jim Hoglund
Ranch Hand

Joined: Jan 09, 2008
Posts: 525
A bit more housekeeping... I cannot find the definition of HttpRequest.
And what about the "new new" on line 24?

To be effective wait() and notify() must operate on the same object and in
code synchronized on that object, as you have done with synchronized (bb).
There must be a companion bb.notify() somewhere, usually in a different
thread. Can you show this code too?

Jim ... ...
Zaeed McColin
Ranch Hand

Joined: Jan 13, 2009
Posts: 90
O god, forgive my stupidness, it's just copy paste problem, so as you said I think that the synchronizing block looks okay, but how, where and when call notify() method?
bty the HttpRequest class is a really simple class which is used for store the socket and streams.
I don't think this class would help but here is HttpRequest class schema.


now it seems we have to call notify() method. so where ?
thanks Jim, thanks guys.
Jim Hoglund
Ranch Hand

Joined: Jan 09, 2008
Posts: 525
Here's a condensed version without wait(), notify() or synchronized.
Instead, it uses Thread.yield() to wait for the ready() condition.
What do you think?
Jim ... ...
Zaeed McColin
Ranch Hand

Joined: Jan 13, 2009
Posts: 90
Wow, oh god it works, yeah whenever a stream is not ready waits and the go. yeah, thanks Jim you did men. many thanks many thanks.
and now would you mind telling me an abstraction(background) of yield() method? what does this guy do exactly? and how we can use it instead of terrible synch, wait and notify?
with best regards.
thanks
Jim Hoglund
Ranch Hand

Joined: Jan 09, 2008
Posts: 525
From the java.lang API, static method Thread.yield() "causes the currently executing thread
object to temporarily pause and allow other threads to execute." It returns void.

Jim ... ...
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18760
    
  40

Jim Hoglund wrote:Here's a condensed version without wait(), notify() or synchronized.
Instead, it uses Thread.yield() to wait for the ready() condition.
What do you think?



This is, in effect, a spin wait. Depending on how blocking yield() is, and it isn't much, you can effectively eat up a ton of CPU cycles. If you have a bunch of these in your applications, you can probably bring your application down to a crawl.

Henry
Jim Hoglund
Ranch Hand

Joined: Jan 09, 2008
Posts: 525
Henry: Yes, it's a spin but it should not cause the JVM to starve other
threads. Is there an alternative approach you would suggest? Arash,
if you are concerned about this, a probe can be added to see how much
CPU yield() is using.

Jim ... ...
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18760
    
  40

There is actually two ways to answer this... so I will do it as two different replies...

Jim Hoglund wrote:Henry: Yes, it's a spin but it should not cause the JVM to starve other
threads. Is there an alternative approach you would suggest?



The correct solution is to figure out why read() is returning EOF when it is not an EOF. When a core API is not behaving correctly, then there is something seriously wrong. So wrong that I would need to understand why. Keep in mind, the incorrect EOF, may just be a symptom, of something really serious, and all the "waiting for ready" is doing is hiding it.

Henry

Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18760
    
  40

Jim Hoglund wrote: Arash,
if you are concerned about this, a probe can be added to see how much
CPU yield() is using.


Keep in mind, that one spin lock is not problem. Two spin locks is likely not a problem. But if you keep doing it -- and if this stuff gets into a library that go in common use, it will eventually become a problem... and by then, it may be too late.

A spin lock (or a spin wait) is something that seems to red flagged in a code review. At least, the code reviews that I have attended (now admittedly, I will red flag it if I catch it first). I have only seen it survived once, and in that case, the developer proved that it is never held too long, and that on average, the lock was held shorter than the time to put the thread into a wait state.

Henry
amitabh mehra
Ranch Hand

Joined: Dec 05, 2006
Posts: 98
Henry, can you elaborate how is that a spin wait. If i use thread.yield() will the thread not yield the cpu to other threads.
coming on top of this is another question which i m not sure is valid or not, still here it is - will yield() method, yield cpu to same and higher priority threads or any thread?
Zaeed McColin
Ranch Hand

Joined: Jan 13, 2009
Posts: 90
thanks Henry for Notify, as you mentioned I've heard that the wait and notify communicate with each other with sending signals, and the waiting thread just should wait for the notify signal, but I haven't used yield() method which Jim suggested, but this method works cool and I don't know about what is happening in background (VM guys), first I have to profile it. as you said Henry the performance is the first word within this project, this little guys shall process many clients at the same time, well the best solution will be used of course.
so how can I implement it with synch block, wait and notify. Jim said the my synch block implementation looks okay, but doesn't call notify, I mean I don't know how and where call this guy. any suggestion with synch, wait and notify? how to?
thanks.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18760
    
  40

amitabh mehra wrote:Henry, can you elaborate how is that a spin wait. If i use thread.yield() will the thread not yield the cpu to other threads.
coming on top of this is another question which i m not sure is valid or not, still here it is - will yield() method, yield cpu to same and higher priority threads or any thread?


Write a single program for this, and you will see that it will eat a ton of processor time. Arguably, you can make a point that even though with lots of these, and the OS showing 100 percent utilization, it won't starve any threads of equal or higher priority (but can starve that of lower priority). I don't really agree with the argument. If you have many of these, you can have lots of threads waking up constantly, to do nothing. This does tax the system. And eventually, something will become an issue. It may not be a starvation, but something will slow down to no longer meet SLAs.

Henry

Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18760
    
  40

Arash M. Dehghani wrote:
so how can I implement it with synch block, wait and notify. Jim said the my synch block implementation looks okay, but doesn't call notify, I mean I don't know how and where call this guy. any suggestion with synch, wait and notify? how to?



My recommendation was to figure out why read() is not working. After all, aren't you curious? Isn't the case of a core API, which has been tested for years, with lots and lots of applications, and not working in your application, scare you a bit? As doesn't that indicate that there is something seriously wrong?

Anyway, no. Wait and notify won't work in this case -- as it is cooperative. And you don't have access to modify the other thread (assuming it is a separate thread that handles the flag for the ready method) to use your synch lock, and notify you. Regardless, even if you can get it work, all you are doing is masking the issue.

Henry
Jim Hoglund
Ranch Hand

Joined: Jan 09, 2008
Posts: 525
This is still working around the problem, but would the following
address concerns about using yield()? Jim ... ...
Zaeed McColin
Ranch Hand

Joined: Jan 13, 2009
Posts: 90
Of course Henry, I've tested it with everything you think, DataInput, reade, InputStream, Buffered,... all reader guys. well as you said it's a low level VM object and its place has been rocked since JDK1.0 of course. well another solution is that use InputStream, and its read method which seems works same as other Stream-related guy, well it seems (I'm not sure) this guys (InputStream) take care of the ready state of the (incoming) stream, but when I try to read the bytes of the stream step by step, as API says, it will returns -1 when end of the stream is reached, wow so it's will be dead easy to handle stream, but as I tested with my Win 2003 and xp, the -1 value is meant Waiting for the InputStream(VM), check the following syntax.

the D part: the whole of the syntax seems okay, at least, I as a simple student see the syntax okay. as Henry mentioned the core API is okay, because I've tested the Stream, and socket related guys with URL, and Socket class for parsing stream which is send from server, and they deadly worked, wow, why doesn't work here?
Jim cool guy, your solution is worked, but according to my application profile, your suggested solution, won't okay for a server, it eats the CPU. and the second solution looks better, but clients should not wait even for 1 micro second.
Many Many thanks guys.
Zaeed McColin
Ranch Hand

Joined: Jan 13, 2009
Posts: 90
Sorry, Sorry guys, I've reviewed the API and got that the ready state of the stream is managed by a method called available(), an wow the problem is solved, Many thanks, sorry guys, with 21 messages I've got your rich time, anyway many Thanks Henry, you notified me about a very important point, (reading API once more time).
Thank you Jim.
Zaeed McColin
Ranch Hand

Joined: Jan 13, 2009
Posts: 90
wow,wow,wow, hi guys, it's me again, sorry for my pertness, anyway, I've tried this guy and it works okay and, is friend with CPU(I think), but it's recommended you Threading guys accept this solution. is this solution okay or not?is it right way?
thanks

what's your Idea? thanks.
Matt Cartwright
Ranch Hand

Joined: Aug 25, 2008
Posts: 149

looksquiteoktomeeventhoughtitishardtoreadbutdon'tknowwhattorecommend
M
Jim Hoglund
Ranch Hand

Joined: Jan 09, 2008
Posts: 525
Arash, What learning have you applied from our earlier conversations? Your code
is still very hard to read and should be clean before it is posted. I will take another
look, and I'm sure Henry will also, if you:

1) Explain what is different from before,
2) Why you made these changes, and
3) Post clean code.

Jim ... ...
Zaeed McColin
Ranch Hand

Joined: Jan 13, 2009
Posts: 90
Sorry Jim, as I said I found a solution then I introduced it to Sockets guys and we found that the solution won't okay for low-bandwidth connection, then I tested this solution (edited above syntax [sorry for formatting]), well as Henry mentioned it's not possible to implement it with wait and notify, so I tried it with empty statement instead of wait and notify, the question is that it's okay that I use semi-intolerable loop instead of wait(), and according to my profile, deposit yield() method it friends with CPU. Sorry for terrible syntax.
Thanks
 
Consider Paul's rocket mass heater.
 
subject: reader interface, wait() then go