"This method blocks until..." means what exactly?

[Nigel Wade]

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.

 

[Screamin Lord Byron]

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.

 

[Arved Sandstrom]

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

 

[Tom Anderson]

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

 

[Arved Sandstrom]

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.

 

[Tom Anderson]

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/[email protected]/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_net...ows_-_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-92f...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

 

[Jim Gibson]

..

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.

 

[ClassCastException]

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.

Well, it seems that

a) I was right that it "depends who you ask".
b) There are two perspectives at odds here:
1) That of the caller, who is solely interested in whether the callee
will usually (always?) return very quickly (less than 1ms, say) or
not, regardless of whether the callee is CPU-bound or I/O-bound, as
the caller is blocked from making progress until the callee returns
regardless; and
2) That of the callee, who is interested in whether they are making
progress (perhaps on a long calculation) or are blocked waiting on
an external actor (or a nested, blocking method call).