"This method blocks until..." means what exactly?
in [Java Programming]
|
Prev: Process ID in Windows the best way
Next: JBR , RENT TO OWN or BUY WITH NO MONEY DOWN ,050-8320722
From: ClassCastException on 28 Jul 2010 22:22 On Wed, 28 Jul 2010 16:24:11 +1000, Esmond Pitt wrote: > On 27/07/2010 12:43 PM, ClassCastException wrote: >> In practice, methods documented as blocking on some I/O event or >> monitor usually also yield the CPU to other threads rather than chew up >> cycles while blocking. > > And in theory. That's what 'block' means. That apparently depends who you ask. As I noted, "block" is normatively used for these cases, but another poster to this thread defined it basically as "does the job synchronously; does not return quickly while another thread continues the task, or fail-fast if it can't do it right away". The latter admits long-running computations and busy-waiting as well as yielding at a monitor or similarly. I was noting that in actual practice the term doesn't normally seem to be used for long-running computations. (Busy-waiting, given modern hardware, tends to be a bug; either it drains the battery wastefully (iPhone) or the system multitasks and other tasks will get starved (just about everything else).) Of course, long-running computations are uncommon outside specialized mathematical/numeric apps and non-real-time rendering (audio, video processing, ray-tracing; generating the SFX for movies like Avatar; sometimes even big compile jobs, though these days in modern development environments compilation is typically quick or even incremental and ongoing, so I'd expect long compile jobs to mainly be the province of kernel developers these days, who are stuck sometimes using legacy environments like command-line C and C++ compilers).
From: Arved Sandstrom on 29 Jul 2010 05:21 ClassCastException wrote: > On Wed, 28 Jul 2010 16:24:11 +1000, Esmond Pitt wrote: > >> On 27/07/2010 12:43 PM, ClassCastException wrote: >>> In practice, methods documented as blocking on some I/O event or >>> monitor usually also yield the CPU to other threads rather than chew up >>> cycles while blocking. >> And in theory. That's what 'block' means. > > That apparently depends who you ask. As I noted, "block" is normatively > used for these cases, but another poster to this thread defined it > basically as "does the job synchronously; does not return quickly while > another thread continues the task, or fail-fast if it can't do it right > away". The latter admits long-running computations and busy-waiting as > well as yielding at a monitor or similarly. [ SNIP ] A "blocking" function doesn't return until its work is completed. Period. That's the only "in theory" associated with the term. A person can invent a more specific definition for a given situation but then they should be prepared to explain themselves. AHS -- I'm not a vegetarian because I love animals. I'm a vegetarian because I hate plants. -- AW Brown
From: Screamin Lord Byron on 29 Jul 2010 06:10 On 07/28/2010 08:24 AM, Esmond Pitt wrote: > On 27/07/2010 12:43 PM, ClassCastException wrote: >> In practice, methods documented as blocking on some I/O event or monitor >> usually also yield the CPU to other threads rather than chew up cycles >> while blocking. > > And in theory. That's what 'block' means. We are mixing some different notions here which could be confusing for the OP. Block means block, nothing else. If the method decides to chew up CPU until it is finished it's still a blocking method if it doesn't return immediately. That's all there is to it.
From: Screamin Lord Byron on 29 Jul 2010 06:17 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).
From: ClassCastException on 29 Jul 2010 23:34
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. SwingWorker is a good example. It lets you turn a blocking operation (such as I/O) into a non-blocking one suitable for calling from the Swing event dispatch thread (EDT). So if you have "readHugeFile();" in an action listener the EDT waits for this (presumably blocking) IO operation and the UI becomes unresponsive. But you can make a SwingWorker that implements its work method to call readHugeFile() and store the resulting data structure in some instance variable of your SwingWorker subclass and invoke the SwingWorker on the EDT. The file is then loaded in some other thread. After that, the SwingWorker's done() method is called on the EDT. You can implement the done() method to do something, like display the data structure from the ivar in a window. Indeed this is how you would implement the File Open command in a multi- document editor implemented with Swing where documents are often very large objects. The Open command would produce a file selection dialog and okaying rather than canceling this would trigger a SwingWorker to load the document off the EDT whose done() method would spawn a new JFrame (or JInternalFrame) to display the newly-opened document. While you were waiting for your document to open though you could work on some other open document or poke around in the Preferences or something. (The remaining UI issue raised is the possibility that the newly opened window will steal input focus while the user is working on something else. If documents open quickly, you may just want to load them on the EDT; if they sometimes load very slowly, though, it's best to let the user keep working on others meanwhile, and then it's necessary to deal with the possible focus swipe issue.) |