Re: NIO and accepts()
From: Cyrille \ (cns2_at_cns.invalid)
Date: 12/15/03
- Next message: Programmer Dude: "Re: What IS Intelligence"
- Previous message: E Tepp: "Pause Util Value is returned"
- In reply to: Douwe: "Re: NIO and accepts()"
- Next in thread: Douwe: "Re: NIO and accepts()"
- Reply: Douwe: "Re: NIO and accepts()"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 15 Dec 2003 19:29:36 GMT
> I´m not sure that NIO was written to outperform the classic IO
> (specific Socket).
The classic blocking socket scheme does not scale well and this is why
writing a powerful server in Java wasn't reasonable. I thought that NIO
had been written to solve this problem.
> In a multiple threaded program you have to make sure that you are the
only one writing to that file in a
> single threaded program you just write you´re data (since you are
> already sure you are the only thread writing data to the disk at that
> moment).
I've written servers in which only one thread at a time handles a client.
I have the program spawn N "worker threads" (typically N=2*CPU) which
enter a sleeping state. Handles (sockets, files, memory...) are
registered with a queue and when something happens on one of the handles
(the queue for that handle isn't empty), the operating system awakens one
of the worker threads which handles the event.
If a resource has to be shared within several threads (for instance you
wish to count bytes sent/recv) then the thread posts its job to the queue
associated with the resource and asynchronously waits for it to complete.
> Unfortunately a single threaded program has some disadvantages as well:
if one client sends erronous data and causes
> the thread to go into a locked state then this means all other client
> handling is blocked as well.
Right. So are dead threads in a MT program a vulnerability, and for this
reason I happen to think that single threaded models are better because
you can't go away with that sort of problem.
You say that the accept method is slow and you´ve probably expected that
NIO would solve this. Unfortunately
> you still have to call the accept method although you are sure (by
> using the selector) it will not block, it still has to initialize the
> socket structure (which I think takes some time) and since the program
> is single threaded all your clients have to wait.
Then Java lacks an asynchronous accept() method.
>> Is it good practice to have multiple threads waiting on select() on
>> the same Selector ?
>
> No.....
> I don´t understand why you want to use a combination of a Selector and
> also use multiple Threads. In a multiprocessor environment a multi
> threaded program will almost always outperform a single threaded
> program (depending on the design of the programs and on the programs
> algorithm).
On multiprocessor architectures the 1 thread per client model doesn't
scale well either. Even though the maximum number of clients is higher,
it is still too small.
On a 4 CPU machine, I'd typically want to have 8 threads processing IO
requests. If I use a single threaded progam, the thread would only run on
one CPU at a time which does not take advantage of the 3 other CPUs.
> you could use a selector in each thread where you handle mulitple
clients. This you should only do if you have a very
> large number of clients connecting and a small number of CPUs.
You mean if have N threads and M clients, I'd give M/N clients to each
thread to handle ? That doesn't solve the accept issue (which can be only
done by one thread) and I'd rather have N threads handling M clients.
Thanks for your helpful thoughts.
--
_|_|_| CnS
_|_| for(n=0;b;n++)
_| b&=b-1; /*pp.47 K&R*/
- Next message: Programmer Dude: "Re: What IS Intelligence"
- Previous message: E Tepp: "Pause Util Value is returned"
- In reply to: Douwe: "Re: NIO and accepts()"
- Next in thread: Douwe: "Re: NIO and accepts()"
- Reply: Douwe: "Re: NIO and accepts()"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
