Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.unix.programmer > #1063

Re: Non-deterministic behavior of multithreaded software

Show all headers | View raw

BGB <cr88192@hotmail.com> writes:

[...]

>> 2. Is it a bad idea to have multiple threads for the same fd. If yes
>> than how to increase capacity of a software that receives large amount
>> of data on a single fd only.
>>
>
> 2A. yes, all sorts of nasty things can happen when sharing
> fd's/... between threads.

Generally, 'all sorts of nasty things can happen' when code doesn't
work as it would need to. And your statement means little more than
that especially as file descriptors referring to different kind of
resources (eg, a listening stream socket, a connected accepted on such
a socket or a datagram socket) have wildly different behaviour.

[...]

> 2B. if it is a CPU bound operation, then one can try
> message-passing. in this case, a single thread manages IO, passing
> input to worker threads via job-queues or similar, and receiving
> results either in the job-queue objects, or via an output queue.

A nice quote on this:

	The simplest conceptual model of a multi-threaded event-driven
	server has a queue at its center; requests are read by one or
	more "listener" threads and put on queues, from which one or
	more "worker" threads will remove and process
	them. Conceptually, this is a good model, but all too often
	people actually implement their code this way. Why is this
	wrong? Because the #2 cause of context switches is
	transferring work from one thread to another. Some people even
	compound the error by requiring that the response to a request
	be sent by the original thread - guaranteeing not one but two
	context switches per request. It's very important to use a
	"symmetric" approach in which a given thread can go from being
	a listener to a worker to a listener again without ever
	changing context. Whether this involves partitioning
	connections between threads or having all threads take turns
	being listener for the entire set of connections seems to
	matter a lot less.
	http://pl.atyp.us/content/tech/servers.html

This is, of course, only 'wrong' when request processing performance
aka request-to-response-latency is actually the most important
concern.

Back to comp.unix.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Non-deterministic behavior of multithreaded software itt ium <ittium@gmail.com> - 2011-08-05 02:38 -0700
  Re: Non-deterministic behavior of multithreaded software Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-05 15:41 +0100
  Re: Non-deterministic behavior of multithreaded software BGB <cr88192@hotmail.com> - 2011-08-05 14:46 -0700
    Re: Non-deterministic behavior of multithreaded software Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-05 23:04 +0100
      Re: Non-deterministic behavior of multithreaded software BGB <cr88192@hotmail.com> - 2011-08-05 18:54 -0700
        Re: Non-deterministic behavior of multithreaded software Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-06 14:59 +0100
          Re: Non-deterministic behavior of multithreaded software BGB <cr88192@hotmail.com> - 2011-08-06 20:29 -0700
            Re: Non-deterministic behavior of multithreaded software Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-07 20:02 +0100
              Re: Non-deterministic behavior of multithreaded software BGB <cr88192@hotmail.com> - 2011-08-07 18:09 -0700
                Re: Non-deterministic behavior of multithreaded software ittium <ittium@gmail.com> - 2011-08-09 09:48 +0530

csiph-web