Re: Re: Asynchronous Completion Token

Hum, just think something like "it is done when it is
done".
With Asynchronous Completion Token (yes, it is more
like the future thing in java.util.concurrent -
we'call it ACT) we'll avoid blocking since the thread
that enqueued the event to be processed will be
notified sometime in the future when the event is
processed.

The idea behind this concept is the same of the
asynchronous IO. We can estabilish much more
connections coming from sockets than if we're
blocking.

I guess that the main idea is not to block enqueue
something but not to block dequeue instead.

(This idea solved a problem I had once).
Hope this helps.

Jean Rodrigues







 --- Quartz <[email protected]> escreveu: 
> > 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
> _______________________________________________
> SEDA-users mailing list
> [email protected]
>
https://lists.sourceforge.net/lists/listinfo/seda-users
>  


	
	
		
_______________________________________________________ 
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/