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

Groups > comp.unix.programmer > #1066

Re: Non-deterministic behavior of multithreaded software

Show all headers | View raw

BGB <cr88192@hotmail.com> writes:
> On 8/5/2011 3:04 PM, Rainer Weikusat wrote:
>> 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.
>>
>
> the particular issue with fd's though is that when being shared
> between threads, one can end up with "slice-and-dice" input or output,
> as each read-request or write-request ends up interspersed with those
> from other threads.

I intentionally gave three examples with two of them being immune to this
problem: Any number of threads can block in accept, as soon as a
thread returns, it will have a file descriptor for an accepted
connection, not 2/3 of such a file descriptor. The same is true for
receive operations on 'I/O channels' which preserve message boundaries
(and I strongly suspsect that the OP is doing this): A thread
returning from such a receive call will always have read a complete
message.

Your statement about 'file descriptors' is way too general to make
sense. Actually, the only thing it applies to is 'I/O channels with
bytestream semantics', eg, stream sockets, pipes, FIFOs and regular
files. And it basically just means 'multiple independent "executable
things" need to coordinate accesses to shared ressources'. In some
cases, this coordination happens inside the kernel, in some other
cases, it needs to be coded into the application.

[...]

>>> 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.
>
> yeah.
>
> another thing is:
> if request/response latency and context-switches actually become a
> performance issue, then the level of granularity is likely far too
> small, and likely better would have been to just use a single
> thread.

I assume that you are convinced that this makes sense because you were
thinking about something specific while typing this 'reminder to self'
note but the words, as they are written down, are pretty much total
nonsense: Average/ medium request/response latency is 'the
performance' (of some server) expressed as a number
(simplified). Context switches are a specific kind of operation taking
place when one thread 'passes work' to some other thread: Assuming the
server isn't already overloaded and actually buffering requests on the
queue because they arrive faster than the responses can be generated,
it means that a currently running thread needs to be put to sleep
despite it has all the information ('the request') necessary to
continue processing available while a currently sleeping thread that
doesn't have this information available needs to be awoken in order to
receive it so that it can do the processing. Technically, that's just a
nonsense operation because it is pure overhead. The advantage is that
the design becomes simpler when threads are used as 'specialized
execution units' as if they were independent parts of a real machine
design to perform a specific function and incapable of doing anything
else. But this limitation of physical things doesn't really exist for
threads: They are all created equal in the sense that every thread can
run all of the code any other thread can also run which implies that
the transport overhead implicit in the 'geographically distant
funtional units with different purposes' model can be avoided.

> also, I was assuming that the operations would be queued up and
> handled asynchronously. if synchronous handling is needed, well then,
> there is no good reason to be using multiple threads in this case, as
> multiple threads will not improve performance in this case (one thread
> will simply end up sitting idly waiting for the other to complete).

Multiple threads can handle multiple requests 'synchronously' in
parallell if such parallell request handling is possible.

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