Re: Re: Asynchronous Completion Token
Quartz <[email protected]> Tue, 23 Nov 2004 08:22:11 -0800 (PST)
| Newsgroups | gmane.comp.java.seda.user |
|---|---|
| Message-ID | <[email protected]> |
> But, in fact, if we can`t slow it down (I mean, we`re > not allowed to slow it because the system must be > responsive)? (That happened to me when I worked for a > telecom). Everything has to be in real time. Blocking surely > will slow all down and create a network queue (for > example). > > We`ll just transfer the chaos from the slow (or less > performing stage) stage to the other stage. So? You need to re-read your books on real-time systems. Rule #1: Overall, consumers must be faster than producers. > The main idea of what I said is that we can try to > increase overall performance of the system by trying > to avoid everything that blocks. First, blocking does not cost anything (beside 2 context switch). The non-blocking argument is only to avoid too many threads and lacking scalability. As long as no more threads are allocated upon backpressure instead of the TM mistakenly thinking the stage is choking, you will be fine. __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.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/