Re: Is Message passing good approach for multi-threaded applications?
- From: John Koleszar <jkoleszar@xxxxxxxxx>
- Date: Wed, 23 Jul 2008 15:11:28 -0400
On Wed, 2008-07-23 at 19:16 +0200, Rainer Weikusat wrote:
John Koleszar <jkoleszar@xxxxxxxxx> writes:
Guess what -- well written servers avoid this by using non-blocking and
other asynchronous I/O methods.
There is no 'nonblocking I/O' for disk files.
I know that O_NONBLOCK doesn't apply to disk files with regular
read/write calls, but was under the impression that using the posix
async i/o interface (aio_read and friends) wouldn't put a process into
the i/o wait state, which is what I meant with the comment about 'other
aio methods'. I very well could be wrong though, my programs are all CPU
bound so I never run in to this.
Either way, I'd be interested to know if this behavior is written into
the/a standard or if it's just reflective of how it's implemented in a
particular kernel.
There may be the occasional case where you know this is safe to do.
But I've seen this fail horribly for reasons like the above more times
than I care to mention.
That may well be the case, but it's just sloppy programming, not a
technical limitation. Frankly, if someone can't get this right, I
wouldn't trust them to get a multithreaded implementation right either,
given the extra complexities involved.
There is no 'extra complexity' involved in multithreading which does
not exist without (minus "but it didn't already exist when I was much
younger!"-factor this phrase IMO decodes to).
I agree with your point that a multithreaded application isn't any more
complicated than an /equivalent/ multiprocess or even uniprocess
application. What I was alluding to, and didn't express well, is that
IME many people /create/ complexity when multithreading through changes
in their architecture, not that the concurrancy and synchronization part
of it is all that hard. For example, an app that could be implemented as
a select() loop on a couple fds with some processing often gets turned
into a thread per client plus separate processing thread. The extra
complexity I'm speaking of is turning the input into an event structure
to pass to the processing thread, managing an event queue, returning the
results to the I/O thread so it can send them to the client, etc. This
is duplicating functionality you get for free or just don't need in the
single threaded case for the sake of design aesthetics. An app that did
the processing in the same thread as the I/O would be basically
equivalent in complexity to the single thread one.
Threads are a crutch for people too lazy to write state machines,
Despite rumours to the contrary, userspace threading is still a stupid
idea.
Fundamentally I agree with you, but it's useful in the multi-processor
case, as it's the most portable abstraction of shared memory there is.
(across all including non-unix os's, OT here)
.
- References:
- Is Message passing good approach for multi-threaded applications?
- From: Behzad
- Re: Is Message passing good approach for multi-threaded applications?
- From: Bin Chen
- Re: Is Message passing good approach for multi-threaded applications?
- From: David Schwartz
- Re: Is Message passing good approach for multi-threaded applications?
- From: John Koleszar
- Re: Is Message passing good approach for multi-threaded applications?
- From: Rainer Weikusat
- Is Message passing good approach for multi-threaded applications?
- Prev by Date: Re: gdb vs fortran RTL -- fight for SIGSEGV
- Next by Date: Re: Is Message passing good approach for multi-threaded applications?
- Previous by thread: Re: Is Message passing good approach for multi-threaded applications?
- Next by thread: Re: Is Message passing good approach for multi-threaded applications?
- Index(es):
Relevant Pages
|
