"This method blocks until..." means what exactly?
in [Java Help]
|
Prev: Process ID in Windows the best way
Next: JBR , RENT TO OWN or BUY WITH NO MONEY DOWN ,050-8320722
From: Martin Gregorie on 30 Jul 2010 20:09 On Fri, 30 Jul 2010 21:51:13 +0200, Screamin Lord Byron wrote: > On 30.07.2010 05:34, ClassCastException wrote: >> On Thu, 29 Jul 2010 12:17:45 +0200, Screamin Lord Byron wrote: >> >>> On 07/26/2010 08:27 AM, Mike Barnard wrote: >>>> Hi. >>>> >>>> Reading the documenation for InputStream methods shows this phrase >>>> used a lot. Whats its definition? >>>> >>>> My best guess is, in the case of read(), that the thread the call is >>>> in will hang up until a chatacter is found by read()? And if like me, >>>> one does not have an application with multiple threads it will hang? >>> >>> That's right. And if some method was defined as a non-blocking method, >>> then it would return immediately (with no actual result of it's work) >>> allowing your app to continue. Of course, you would have to check for >>> the result later (with some other method). >> >> Actually, it's quite a common pattern to register some kind of callback >> to be invoked automatically when the result is ready. > > Sure, but if you expect your code to be run only in a single thread > (like OP said) you probably wouldn't want that. Depends whether there's a rendezvous and dispatch method that will block until something of interest to the program happens. Not having yet had any need to use the NIO classes I can only quote C experience: a C server based round select() as the blocking rendezvous can easily handle multiple clients without needing more than the single main execution thread provided only that the actions triggered by an event that causes select() to return are fast compared to the average arrival rate of client requests. As a bonus, there are never locking issues to deal with regardless of whether client sessions are stateless or stateful: the only difference is that stateful sessions require private storage for each session while stateless sessions, which usually don't extend over more than a single transaction, don't need private storage. If the actions are slower than the average request arrival rate (typically because at least some of the actions block), then and only then there is a case for using multiple processing threads. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Nigel Wade on 2 Aug 2010 05:39 On 30/07/10 20:38, Screamin Lord Byron wrote: > On 30.07.2010 12:20, Nigel Wade wrote: > >> I infer "blocking" to imply: >> >> a) no useful work is being performed >> b) the duration is indeterminate (usually due to external factors) >> >> whether it yields the CPU to other threads, or spins, isn't material to >> the meaning of "blocked" - it may do either. > > Wouldn't you say that a function which does some time consuming > cryptographic computation (like generating long RSA keypairs) blocks if > it doesn't return before the computation is finished? > No, I wouldn't. To me, if it's actually performing its allotted task then it's running, not blocked. If it were blocked then it would be doing nothing, unable to perform it's required task (generally because it's waiting for some event to occur). That's why the term "blocked" is used (similar to when a road is blocked), it can't perform its function because something is preventing it. If it's running, doing what it's meant to do, I would not consider it blocked. -- Nigel Wade
From: Screamin Lord Byron on 2 Aug 2010 10:52 On 02.08.2010 11:39, Nigel Wade wrote: > On 30/07/10 20:38, Screamin Lord Byron wrote: >> On 30.07.2010 12:20, Nigel Wade wrote: >> >>> I infer "blocking" to imply: >>> >>> a) no useful work is being performed >>> b) the duration is indeterminate (usually due to external factors) >>> >>> whether it yields the CPU to other threads, or spins, isn't material to >>> the meaning of "blocked" - it may do either. >> >> Wouldn't you say that a function which does some time consuming >> cryptographic computation (like generating long RSA keypairs) blocks if >> it doesn't return before the computation is finished? >> > > No, I wouldn't. > > To me, if it's actually performing its allotted task then it's running, > not blocked. If it were blocked then it would be doing nothing, unable > to perform it's required task (generally because it's waiting for some > event to occur). That's why the term "blocked" is used (similar to when > a road is blocked), it can't perform its function because something is > preventing it. If it's running, doing what it's meant to do, I would not > consider it blocked. OK. If I understood correctly -- if some thread A calls some function foo() and foo() blocks thread A, then foo() is a blocking function. On the other hand, if thread A calls bar() and bar() spawns a new thread B and blocks it for the same reason, but return immediately after spawning, then bar() is non-blocking (from the perspective of the thread A). Now, if thread A calls function baz() which does some time consuming work but doesn't block thread A, then bazA() is still non-blocking (because thread A isn't blocked). Imagine that we have some function bazB() which does the same work as bazA, but in a new thread B and return immediately. Now, I still have a problem how to differentiate functions bazA() and bazB(). Let's say I'm using two processors. If I call bazA(), one of my processors must idle until the calculation is done, but if I call bazB() I can do some useful work on my other processor while the calculation is being done.
From: Arved Sandstrom on 2 Aug 2010 15:54 Nigel Wade wrote: > On 30/07/10 20:38, Screamin Lord Byron wrote: >> On 30.07.2010 12:20, Nigel Wade wrote: >> >>> I infer "blocking" to imply: >>> >>> a) no useful work is being performed >>> b) the duration is indeterminate (usually due to external factors) >>> >>> whether it yields the CPU to other threads, or spins, isn't material to >>> the meaning of "blocked" - it may do either. >> Wouldn't you say that a function which does some time consuming >> cryptographic computation (like generating long RSA keypairs) blocks if >> it doesn't return before the computation is finished? >> > > No, I wouldn't. > > To me, if it's actually performing its allotted task then it's running, > not blocked. If it were blocked then it would be doing nothing, unable > to perform it's required task (generally because it's waiting for some > event to occur). That's why the term "blocked" is used (similar to when > a road is blocked), it can't perform its function because something is > preventing it. If it's running, doing what it's meant to do, I would not > consider it blocked. > Yeah, but that's to "you". The general definition is simply that a blocking (synchronous) method does not return until it has finished its work, or it fails. That's it. AHS -- Give a man a fish, and he can eat for a day. But teach a man how to fish, and he'll be dead of mercury poisoning inside of three years. --Charles Haas
From: Tom Anderson on 2 Aug 2010 19:09
On Mon, 2 Aug 2010, Arved Sandstrom wrote: > Nigel Wade wrote: >> On 30/07/10 20:38, Screamin Lord Byron wrote: >>> On 30.07.2010 12:20, Nigel Wade wrote: >>> >>>> I infer "blocking" to imply: >>>> >>>> a) no useful work is being performed >>>> b) the duration is indeterminate (usually due to external factors) >>>> >>>> whether it yields the CPU to other threads, or spins, isn't material to >>>> the meaning of "blocked" - it may do either. >>> >>> Wouldn't you say that a function which does some time consuming >>> cryptographic computation (like generating long RSA keypairs) blocks >>> if it doesn't return before the computation is finished? >> >> No, I wouldn't. >> >> To me, if it's actually performing its allotted task then it's running, >> not blocked. If it were blocked then it would be doing nothing, unable >> to perform it's required task (generally because it's waiting for some >> event to occur). That's why the term "blocked" is used (similar to when >> a road is blocked), it can't perform its function because something is >> preventing it. If it's running, doing what it's meant to do, I would >> not consider it blocked. > > Yeah, but that's to "you". The general definition is simply that a blocking > (synchronous) method does not return until it has finished its work, or it > fails. That's it. Evidence for this assertion, please. I'm more or less with Nigel. I'm not bothered about whether the CPU is busy, or whether useful work is being done, but to me, blocking means that a method doesn't return *until some external actor causes it to*. The long-running cryptographic function is not blocking, because it doesn't require any external input to finish. A normal IO method is, because it can get stuck waiting for hardware. It seems to me that if you call the cryptographic function blocking, then you have to call every function blocking, because no function returns before the computations it performs are finished (although i understand there's a Clojure extension for time-travel). That seems like a remarkably useless definition of the term. tom -- What we learn about is not nature itself, but nature exposed to our methods of questioning. -- Werner Heisenberg |