Re: R: GOBACK (was: Perform Thru/Go to vs. Perform - Compile Speed
From: Michael Wojcik (mwojcik_at_newsguy.com)
Date: 05/27/04
- Next message: Donald Tees: "win98 to XP"
- Previous message: Robert Wagner: "Re: Sign Problem---Following example"
- In reply to: Richard: "Re: R: GOBACK (was: Perform Thru/Go to vs. Perform - Compile Speed"
- Next in thread: Joe Zitzelberger: "Re: R: GOBACK (was: Perform Thru/Go to vs. Perform - Compile Speed"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 26 May 2004 22:01:38 GMT
In article <217e491a.0405251728.2def7b1@posting.google.com>, riplin@Azonic.co.nz (Richard) writes:
> mwojcik@newsguy.com (Michael Wojcik) wrote
>
> > The server can wait for any
> > I/O event: new conversation, data available from client on existing
> > conversation, client ready to receive on existing conversation with
> > pending response data, file I/O ready, and so forth, and service
> > each event as it fires.
>
> Certainly a program can do this if it works at a low enough level and
> handles interrupts directly, or can get the OS to block on enough
> services, or polls.
Under Unix, any process can wait for any I/O event using select or
poll; some Unix variants (eg Solaris) provide other, superior
mechanisms in addition, but anything Unix-branded has poll.
Under Windows, the simplest form of I/O multiplexing is unfortunately
limited by the 64-object limit in WaitForMultipleObjects, but there
are alternatives (overlapped I/O in particular). And a compromise
that uses one thread for every 64 objects is still a huge improvement
over thread-per-conversation.
That's only two OSes, but they're the dominant ones for this sort of
thing. Not that many people are writing web servers for MVS, or for
embedded devices, and so forth; those are largely the domains of a
relatively few experts.
> One case where I have had to resort to multi-threading (or
> multi-tasking on shared data and code segments) is where the OS could
> only block on each resource separately.
Certainly. I was referring to the most common case today, which is
a server running on Unix or Windows. Such creatures proliferate
beyond all reason, and they often use multithreading unwisely.
> You may well call that a poor OS design that required me to do that.
I'd call it a strange OS design that supports general-purpose
multithreading but not I/O multiplexing; but an OS that provides
something similar to multithreading (such as your example of
multitasking in a common address space) wouldn't be unusual in some
environments.
> I expect that, at least to some extent, a server may be in the same
> position. As the concurrency increases it becomes increasingly
> difficult to ensure that you get each 'firing', unless it has control
> over, say, the disk i/o queue.
If the OS supports multiplexed I/O correctly, that shouldn't be a
problem. On the other hand, trying to schedule as many threads as
there are conversations efficiently as concurrency increases is
obviously problematic. And in general, any time you have more
(preemptively scheduled) threads than you have CPUs, you're wasting
some CPU time in scheduling them. If multiplexed I/O is implemented
correctly, it doesn't waste any CPU time - the server only uses CPU
to do task processing, and only goes idle when there's no work to
be done.
-- Michael Wojcik michael.wojcik@microfocus.com Thanatos, thanatos! The labourer, dropping his lever, Hides a black letter close to his heart and goes, Thanatos, thanatos, home for the day and for ever. -- George Barker
- Next message: Donald Tees: "win98 to XP"
- Previous message: Robert Wagner: "Re: Sign Problem---Following example"
- In reply to: Richard: "Re: R: GOBACK (was: Perform Thru/Go to vs. Perform - Compile Speed"
- Next in thread: Joe Zitzelberger: "Re: R: GOBACK (was: Perform Thru/Go to vs. Perform - Compile Speed"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
