On Tue, May 12, 2009 at 5:56 PM, Jeanfrancois Arcand <
Jeanfrancois.Arcand_at_sun.com> wrote:
> Salut,
>
> John Franey wrote:
>
>> Hi,
>>
>> I'm trying to get a handle on how threads are being used in
>> 1.9.16-SNAPSHOT (svn r3170). I currently have two areas of outstanding
>> questions.
>>
>> 1) I see leader-follower strategy. When in use, a worker thread from the
>> controller's threadpool is used for the SelectorHandlerRunner. When a
>> selected event occurs, delegateToWorker branch of
>> SelectorHandler.handleSelectedKey, the current thread requests another
>> thread to become the selector thread, and handles the key processing itself,
>> returning itself to the thread pool on completion.
>>
>
> So far so good.
>
> This is
>
>> different from a strategy where the selector thread requests another
>> thread to do the key processing, and retains the role as selector thread.
>> Is this correctt?
>>
>
> Yes.
>
> Is this strategy effective if there is more
>
>> than one selector key (event) to process? or, under what conditions is
>> this strategy ineffective/effective?
>>
>
> Usually leader/follower gives better results, but our measurement didn't
> show a boost like we were expected. We got a ~4% boost.
>
>
>
>
>> 2) I see that Controller.autoConfigure sizes readThreadsCount (by the
>> number of processors). This value is used later in Controller.start to
>> create a RoundRobinSelectorHandler; for each of readThreadsCount, a
>> ReadContoller is created. When acceptInterest occurs,
>> RoundRobinSelectorHandler will pick one of the ReadControllers and assign
>> the selected channel to it.
>>
>
> Yes.
>
> Each ReadController runs its own
>
>> SelectorHandler thread, and so, selection work is distributed across a
>> group of threads (sized by the number of processors). It looks like this
>> action of distributing selection across threads will only be activated
>> onAcceptInterest, and in cases where a server does not bind, this won't
>> occur. Is that correct?
>>
>
> Yes. And the performance out-of-the-box is 50% higher.
>
> In absence of onAcceptInterest
>
>> callbacks (no binding), can selection work be distributed across threads?
>>
>
> Can you elaborate about this scenario?
>
Sure. I'm still not connecting all the dots yet, so I hope I make sense.
I'm working on an implementation of an RTP media server. This uses UDP.
UDP doesn't use accept. A peer uses datagram connect with local and
remote ip addresses and starts to send and receive RTP, UDP packets. The
remote ip address is pre-negotiated using a different protocol, not RTP.
There is no connection setup. There is not a bind operation. There is no
connection to accept. I expect the only selected keys would be for either
for OP_READ and OP_WRITE, and OP_CONNECT.
50%, heh? That's a big improvement. In what metric? throughput, cpu
utilization? Do you think its possible for UDP handlers to enjoy this?
Thanks.
John
> Thanks
>
> -- Jeanfrancois
>
>
>
>
>> Thanks,
>> John
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>