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

Groups > comp.unix.programmer > #1069

Re: Non-deterministic behavior of multithreaded software

Show all headers | View raw

BGB <cr88192@hotmail.com> writes:
> On 8/6/2011 6:59 AM, Rainer Weikusat wrote:

[...]

>> 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.
>
> I have before measured the time to go to sleep, switch threads, and
> get control back, to typically be about 50-100ns or so on modern
> systems (granted, this was in the case of multi-threaded programs on
> Windows).
>
> (the above is in contrast to the 1-2us needed to lock a mutex object,
> for whatever reason it takes this long...).

According to a very simplistic experiment I just made, namely,

----------
#include <pthread.h>

unsigned a;

int main(void)
{
    pthread_mutex_t lock;
    unsigned b;

    b = 0xfffffff;
    while (--b) {
    	pthread_mutex_lock(&lock);
	nop(++a);
    	pthread_mutex_unlock(&lock);
    }

    return a;
}
----------

with 'nop' being

void nop(unsigned x) { }

defined in another file in order to 'fool' the gcc optimizer, locking
and unlocking an uncontended mutex takes about 11.6ns on an Intel Core
i3 3.2Ghz-using computer. This means assuming your numbers are
accurate, the operation is an about an order of magnitude faster than
'go to sleep, switch threads ...'. However, I don't quite understand
what you're up to, especially since passing a data item from one
thread to another 'fast' (ie, without copying it through the kernel)
will usually involve operations on a mutex and a condition variable on
both ends.
 
> if the operation itself is something which takes, say, < 10us or so,
> then likely the granularity was too small, and a single thread (or
> multiple independent/parallel threads) would probably have made more
> sense.

Also, I still don't understand what 'granularity' is supposed to mean
here. 

[...]

>>> 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.
>
> potentially.

Provided that multiple threads can run in parallell (because more than
a single 'execution unit' exists), they will be able to do parallell
request processing.

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