Nice thing about Java's verbose naming is the name tells you the behavior. It also has a lot of internal documentation in the Java. Such documentation is easily accessible from their IDe or the web.
As the article points out, you can block the producers or consumers. So while queues and threading are advanced for an entirely new concurrency programmer, the are the most fundamental block of the concurrence developer.
I honestly hope author goes more indepth in next part of the article. Most common use case that I have seen for BlockingQueues is to use them in conjunction with ExecutorService and ThreadPoolExecutor.
In that context you have to use/implement Task rejection policies if queue is full. Blocking operation Put on the queue is not used when submitting task to the service, it uses Offer method instead. It's a bit misleading.
One thing that stands out is the article's description of a free (non-busy) thread in a thread pool as "blocked." This is IMHO a misuse of the term--in normal usage, a blocked thread is one that is waiting for a call to complete, whether that's IO, computation, trying to add an item to a full bounded queue configured to make its caller wait rather than fail, etc.
But you're drawing a distinction where none exists. When a thread in a thread pool is "free", what it's doing is waiting for the next item of work to arrive -- and in implementation terms, that means the thread is blocked in a "take" operation on a currently-empty work queue. So it's totally correct to use the term "blocked" in that situation.
It's a free resource in a pool, probably in interruptible wait() or poll(), but don't you think this is an implementation detail and separate topic of discussion from a thread carrying out program logic and stuck on, say, uninterruptible IO?
The take() function is equivalent to a bare <- channel read. the poll(time, timeunit) function is equivalent to a select with a case and a read off the done channel of a context with a timeout. The poll() function is equivalent to a select with a case and a default condition.
To get the behavior of a select composed of several channels and no default case I'd have to dig into the exact behavior of the select statement in go, but it could be accomplished with a loop over if/else if/else statement where the else had a thread sleep/thread yield.
I actually wrote a dsl in Scala a few years back that actually used the keyword select for this operation before I'd ever encountered golang. I used "on" instead of case but the behaviors were nearly identical.
I assume the name came from the select syscall, maybe unconsciously in your case :)
Hopefully something comes along to fill this gap officially. Channels are my favorite concurrency primitive by a huge margin. The more languages that support them, the better.
It wasn't unintentional that I used select. The dsl actually abstracted over network operations first and I only later added queues to the abstraction.
20 comments
[ 3.3 ms ] story [ 53.5 ms ] threadAs the article points out, you can block the producers or consumers. So while queues and threading are advanced for an entirely new concurrency programmer, the are the most fundamental block of the concurrence developer.
In that context you have to use/implement Task rejection policies if queue is full. Blocking operation Put on the queue is not used when submitting task to the service, it uses Offer method instead. It's a bit misleading.
In Python they make it easier to right thread-safe code. I have written a similar article for Python with a focus on thread safety: https://lemanchet.fr/articles/learning-python-3-threading-mo...
[1] https://en.wikipedia.org/wiki/Channel_(programming)
To get the behavior of a select composed of several channels and no default case I'd have to dig into the exact behavior of the select statement in go, but it could be accomplished with a loop over if/else if/else statement where the else had a thread sleep/thread yield.
I actually wrote a dsl in Scala a few years back that actually used the keyword select for this operation before I'd ever encountered golang. I used "on" instead of case but the behaviors were nearly identical.
Hopefully something comes along to fill this gap officially. Channels are my favorite concurrency primitive by a huge margin. The more languages that support them, the better.