Re: Asynchronous Completion Token

Quartz <[email protected]> Thu, 18 Nov 2004 17:38:21 -0800 (PST)
Newsgroups gmane.comp.java.seda.user
Message-ID <[email protected]>
> Jean Rodrigues wrote:
>  > I had a problem similar to what you explained with seda but I solved
>  > it by avoiding blocking stuff.
>  > But an Asynchronous Completion Token implementation should do
>  > something similar, shouldn't it?
> 
> An "Asynchronous Completion Token" like java.util.concurrent.Future?  I 
> don't know how the use of Future could resolve our backpressure problem, 
> but I would be interested to ear you on that subject.


Dudes, there is 4 things a thread can do:
1-work (running, R)
2-acquiring monitor (MW)
3-wait with monitor (blocked, W)
4-notify[all] on monitor

Assuming
you can't block (3),
that notifying is just work (4),
that acquiring monitor (2) is equivalent to work (1) or blocking (3)

(and since you don't want to block, one would assume you made sure the acquisition is fast, so it
is like work (1))

then you are left with work (1) only, or your thread is simply dead or not in that stage.
That means your pool must be able to reach in-use-size=0 because a single thread could be enough
to over-produce.

Basically, if a stage is about to block, its thread pool must be emptied quickly.
Otherwise the queue fills and gets lossy. Or if not lossy, you pushed the pending data somewhere
else (the Future thing...?) and you abuse memory until NO thread is handling events.

Think of it another way: how do you choke a thread that is running too fast?
You put it to sleep/wait or you kill it. Lowering its priority is marginal and not reliable, and
yielding isn't gonna change anything. killing it is not performant, so you just return the thread
to the available pool or it must do some other job. Hum, guess what? There is some freaking urgent
job to perform downstream!

Without blocking enqueue, the above is one of the main reasons a thread pool per stage (TPSTM) is
a bad idea, -unless- its size can reach 0, requiring the pool controller to watch the end of
backpressure.

So much for code locality on multiprocessor... And yet, threads are doing multi-task...
Hope this helps.



		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com 
 



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8