Prev: Process ID in Windows the best way
Next: JBR , RENT TO OWN or BUY WITH NO MONEY DOWN ,050-8320722
From: Arved Sandstrom on 3 Aug 2010 05:53
Tom Anderson wrote:
> 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

Evidence for the assertion? A great deal of Googling is what it came
down to, on various combinations of "method", "I/O", "blocking", "block"
and "blocked". I left out "thread" and "threading" entirely, so as not
to confuse the results. I also filtered or weighted based on whether the
context of the discussion was a newish language (Ruby, Java etc) or
something like C; I also included definitions from discussions about
"remote" calls (newish or not: RMI, CORBA, web services etc).

My intention with this searching was to establish a common ground. It's
not perfect; a better but considerably more time-consuming approach
would be to go pre-World Wide Web and consult printed sources. I did
however try to capture sources that were either older, or seemed to be
older in "mindset".

And that's the best definition I arrived at: that a blocking method does
not return until its mission is accomplished. As you know the term is
commonly used in the I/O context and in this case we *are* talking about
the I/O context. Within this context simply defining it the way a lot of
sources use it, as a method that does not return until it succeeds in
doing its work, or it fails, _is_ useful. I was originally addressing
the idea that the definition involved what the method was doing while it
waited (if it waited), and I'm simply saying that for I/O blocking
methods that the useful definition doesn't care. In fact you've stated
so yourself. I don't however think there's any need to garnish the
definition with mention of external actors, which is where we may
differ. It's an I/O method - draw your own conclusions.

I will dispute however that one cannot use the terminology for non-I/O
methods. If we are discussing potentially long-running computations of
any kind, then we can have both synchronous (blocking) computations and
asynchronous (non-blocking *) computations. This terminology is common.

AHS

* Asynchronous being non-blocking, but not necessarily vice versa.

--
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 3 Aug 2010 14:15
On Tue, 3 Aug 2010, Arved Sandstrom wrote:

> Tom Anderson wrote:
>> 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.
>
> Evidence for the assertion? A great deal of Googling is what it came
> down to, on various combinations of "method", "I/O", "blocking", "block"
> and "blocked". I left out "thread" and "threading" entirely, so as not
> to confuse the results. I also filtered or weighted based on whether the
> context of the discussion was a newish language (Ruby, Java etc) or
> something like C; I also included definitions from discussions about
> "remote" calls (newish or not: RMI, CORBA, web services etc).
>
> My intention with this searching was to establish a common ground. It's
> not perfect; a better but considerably more time-consuming approach
> would be to go pre-World Wide Web and consult printed sources. I did
> however try to capture sources that were either older, or seemed to be
> older in "mindset".
>
> And that's the best definition I arrived at: that a blocking method does
> not return until its mission is accomplished. As you know the term is
> commonly used in the I/O context and in this case we *are* talking about
> the I/O context. Within this context simply defining it the way a lot of
> sources use it, as a method that does not return until it succeeds in
> doing its work, or it fails, _is_ useful.

Yes, that's true. But in that context, i'm not sure how you could
distinguish our definitions!

> I was originally addressing the idea that the definition involved what
> the method was doing while it waited (if it waited), and I'm simply
> saying that for I/O blocking methods that the useful definition doesn't
> care. In fact you've stated so yourself.

You're right, we're in violent agreement here.

> I don't however think there's any need to garnish the definition with
> mention of external actors, which is where we may differ. It's an I/O
> method - draw your own conclusions.
>
> I will dispute however that one cannot use the terminology for non-I/O
> methods.

Evidently!

> If we are discussing potentially long-running computations of any kind,
> then we can have both synchronous (blocking) computations and
> asynchronous (non-blocking *) computations. This terminology is common.

It seems entirely alien to me.

Here's my half-arsed statistical contribution. I google for "the * method
is blocking" used as an indicative phrase, and present the first 21
distinct hits which are accessible without registration (ie not a paper
from behind a paywall). For each, i give the URL, the phrase containing
the hit given in the google snippet, and my interpretation of what it is
the method is blocking *until*.



http://www.cs.virginia.edu/~mngroup/hypercast/designdoc/API+Example/api.htm
"We note that the receive method is blocking"
-> arrival of a message from a network

http://blog.rguha.net/?p=651
"The receive method is blocking, so the program will wait for the next
message."
-> arrival of a JMS message on a queue

http://forums.java.net/jive/message.jspa?messageID=389765
"I found out that exactly the getResponseCode() method is blocking."
-> reception of a HTTP status-line

http://java.itags.org/java-core-gui-apis/61647/
"I know that the getNextEvent() method is blocking."
-> arrival of a GUI event

http://forums.sun.com/thread.jspa?threadID=431842
"Unfortunately the fireTimeChangeEvent method is blocking."
-> a called method has finished executing

http://www.interfaceware.com/manual/llp_service.html
"The RunMessageLoop method is blocking."
-> "a POST_QUIT message is sent to the networking thread"

http://hci.rwth-aachen.de/istuff/tutorial_eventheap.pdf
"The waitForEvent method is blocking"
-> "the expected event got posted."

http://blog.gmane.org/gmane.network.iperf.user/month=20100501
"the sendto method is blocking at higher rates"
-> a buffer is drained to the network (i think)

http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/e5e1df1a-960d-43f5-9bf2-829478e7a9e8
"the Run() method is blocking the calling thread with the Join() method"
-> another thread terminates

http://docs.codehaus.org/display/GEOTDOC/Catalog
"the resolve method is blocking"
-> retrieval of data from "disk, remote service, etc"

http://code.google.com/p/jadss/wiki/ProjectArchitecture
"the write method is blocking"
-> a buffer is drained to the sound card

http://www.leighboxing.com/Boxing-Tips
"The most instinctive method is blocking"
-> er, until you see a chance to punch someone, i think

http://bytes.com/topic/c-sharp/answers/381461-xmlserialization-over-networkstream
"the Deserialize method is blocking."
-> a serialized string is received from the network

http://pocoproject.org/docs/Poco.AbstractEvent.html
"This method is blocking."
-> all registered delegates have been notified

http://www.mail-archive.com/android-beginners(a)googlegroups.com/msg10256.html
"in MODE_STEAMING the write method is blocking"
-> a sound clip has been played (i think)

http://www.codeproject.com/KB/directx/OdysseyUI.aspx
"In windows forms the MessageBox.Show method is "blocking"
-> "until the user presses one of the dialog's buttons"

http://www.zanshu.com/ebook/388_network_programming_for_microsoft_windows_-_second_edition/netprog2html/32ch16i.htm
"the Connect method is blocking"
-> "a connection [over the network] is made or an error is returned"

http://sw.nokia.com/id/59c97da0-92fb-4d85-8b7c-3e1b241a6b65/MIDP_Mobile_Media_API_Developers_Guide_v1_0_en.pdf
"the above method [Manager.createPlayer] is blocking"
-> "the media is loaded."

http://foxtrot.sourceforge.net/docs/worker.php
"The Worker.post() method is blocking"
-> "the time-consuming task is finished or throws an exception"

http://smsj.sourceforge.net/apidocs/org/marre/sms/transport/ucp/UcpTransport.html
"Depending on the implementation this method is blocking or non-blocking."
-> an SMS message has been sent "through an UCP SMSC" (i think)

http://www.j2meforums.com/forum/index.php?topic=22037.0
"The getResponse method is blocking"
-> "you receive a response from the server"



One of those is about boxing. Of the 20 that are about computers, the
methods block until:

- something is received from the network (6)
- a buffer drains to somewhere (3)
- some unspecified code finishes executing (3)
- a GUI event occurs (2)
- some unspecified kind of event is received (2)
- some unspecified kind of IO is complete (2)
- a JMS message is received (1)
- another thread terminates (1)

I consider any of the IO-based cases (6 + 3 + 2 = 11), any of the
event-based cases (2 + 2 = 4), the JMS case (1) and the thread termination
case (1) to be waiting for an external actor, for a total of 17. Three of
the cases are clearly about waiting for some arbitary code to complete.
You could quibble about the thread termination case, but then you could
quibble about whether the arbitrary code excludes that which indirectly
blocks on some external actor.

So, of this small sample, 15% could be talking about waiting for something
which may not involve an external actor. Of those, one is from C++, one is
from a newbie on a forum, and one is talking about time-consuming things
that happen behind a GUI, which very often *will* be dependent on some
external actor. I'm not really persuaded that use of the word "blocking"
to describe methods whose completion is not dependent on an external actor
is common.

tom

--
Dreams are not covered by any laws. They can be about anything. --
Cmdr Zorg
From: Jim Gibson on 3 Aug 2010 16:23
In article <gGR5o.10507$Z6.8370(a)edtnps82>, Arved Sandstrom
<dcest61(a)hotmail.com> wrote:

> Tom Anderson wrote:
> > 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)
> >>>>>

..
> >
> > 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
>
> Evidence for the assertion? A great deal of Googling is what it came
> down to, on various combinations of "method", "I/O", "blocking", "block"
> and "blocked". I left out "thread" and "threading" entirely, so as not
> to confuse the results. I also filtered or weighted based on whether the
> context of the discussion was a newish language (Ruby, Java etc) or
> something like C; I also included definitions from discussions about
> "remote" calls (newish or not: RMI, CORBA, web services etc).

There is the Computer Dictionary Online:

"2. <operating system> To delay or sit idle while waiting for
something.

"Compare busy-wait."

I would agree with that definition.

--
Jim Gibson
First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: Process ID in Windows the best way
Next: JBR , RENT TO OWN or BUY WITH NO MONEY DOWN ,050-8320722