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

Groups > comp.programming.threads > #1506

Re: Thread scaling in Windows

Show all headers | View raw

Marcel Müller <news.5.maazl@spamgourmet.org> wrote in
news:51a90f46$0$6626$9b4e6d93@newsspool2.arcor-online.net: 

> On 31.05.13 19.57, Paavo Helde wrote:
>>>> like updating a shared object reference count by a smartpointer.
>>>
>>> This is really expensive! Not only because of the mutex. Writing to
>>> a shared memory location from different cores also invalidates the
>>> related cache content of all cores except for the one currently
>>> writing. So cache misses are very likely to occur after that. The
>>> problem is called cache line hopping, and you simply should not do
>>> that.
>>
>> Right, this is something I have vaguely suspected myself. Trying to
>> get rid of them. But this does not explain the Linux-Windows
>> difference, does it?
> 
> Yes, this is a bit funny. If boost maps to pthreads and the windows 
> implementation of boost uses emulated pthreads, than I would not
> wonder anymore. Emulating pthreads with the Win32 API is somewhat
> complicated at some places and may require time consuming work
> arounds. I had similar fun when porting PulseAudio to the OS/2 API,
> which is almost the same than Win32.

The boost::mutex class we have seems to use compiler intrinsics and SDK 
functions like _interlockedbittestandset and _InterlockedExchangeAdd. At 
least for the uncontented case these were the only functions triggered. 

There are other more complicated classes like boost::timed_mutex and 
boost::recursive_mutex which use more stuff but these are not used so 
often in our code.
 
> You could look for lock-free smart pointers. I think this could be 
> enough to stop this from being the critical path.
> On x86/x64 they are almost as fast as single threaded ones as long as 
> you do not acquire access to the same object from different threads
> all the time.

I already replaced the refcounter mutex lock by InterlockedIncrement and 
InterlockedDecrement SDK functions, but this appeared to make no 
difference. Makes sense, as the mutex locks are using similar atomic 
operations.

> 
>> Shared objects are
>> accessed only occasionally, but this still makes up a lot as it
>> seems. In principle it should suffice to have only one shared object
>> smartpointer in a thread and use C++ references for passing it around
>> in the thread. 
> 
> This is one option. But it might be complicated if it is not that easy
> to track when a thread does not need access to a shared object
> anymore. 
> 
> Another option is to create an interface from the single threaded one
> to the shared smart pointer. The basic idea is that a proxy object
> that adapts the single threaded pointers can be initialized from the
> shared pointer. This proxy acquires a new reference from the shared
> location. But further instances of single threaded pointers only
> increment a local reference counter in the proxy rather than the
> global, shared counter. Only if that shared object goes out of scope,
> the global reference counter is accessed again. This keeps memory
> access thread-local as far as possible.

Yes, that seems like a good idea.

Cheers
Paavo

Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Thread scaling in Windows Paavo Helde <myfirstname@osa.pri.ee> - 2013-05-29 12:31 -0500
  Re: Thread scaling in Windows Robert Miles <robertmilesxyz@gmail.com> - 2013-05-29 17:26 -0700
    Re: Thread scaling in Windows Paavo Helde <myfirstname@osa.pri.ee> - 2013-05-30 16:11 -0500
      Re: Thread scaling in Windows Gerald Breuer <Gerald.Breuer@googlemail.com> - 2013-05-31 03:44 +0200
        Re: Thread scaling in Windows Paavo Helde <myfirstname@osa.pri.ee> - 2013-05-31 00:29 -0500
  Re: Thread scaling in Windows Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-05-30 23:28 +0200
    Re: Thread scaling in Windows Paavo Helde <myfirstname@osa.pri.ee> - 2013-05-30 17:52 -0500
      Re: Thread scaling in Windows Melzzzzz <mel@zzzzz.com> - 2013-05-31 04:18 +0200
      Re: Thread scaling in Windows Robert Wessel <robertwessel2@yahoo.com> - 2013-05-31 01:11 -0500
        Re: Thread scaling in Windows Paavo Helde <myfirstname@osa.pri.ee> - 2013-06-01 12:15 -0500
          Re: Thread scaling in Windows Paavo Helde <myfirstname@osa.pri.ee> - 2013-06-01 16:52 -0500
            Re: Thread scaling in Windows [SOLVED] Paavo Helde <myfirstname@osa.pri.ee> - 2013-06-03 12:00 -0500
              Re: Thread scaling in Windows [SOLVED] Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-06-04 08:16 +0000
              Re: Thread scaling in Windows [SOLVED] Noob <root@127.0.0.1> - 2013-06-04 10:25 +0200
      Re: Thread scaling in Windows Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-05-31 15:53 +0200
        Re: Thread scaling in Windows Paavo Helde <myfirstname@osa.pri.ee> - 2013-05-31 12:57 -0500
          Re: Thread scaling in Windows Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-05-31 22:59 +0200
            Re: Thread scaling in Windows Paavo Helde <myfirstname@osa.pri.ee> - 2013-06-01 03:06 -0500
              Re: Thread scaling in Windows Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-06-01 15:20 +0200
                Re: Thread scaling in Windows Drazen Kacar <dave@fly.srk.fer.hr> - 2013-06-02 06:35 +0000
            Re: Thread scaling in Windows Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-06-01 12:34 +0000
              Re: Thread scaling in Windows Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-06-01 15:09 +0200
                Re: Thread scaling in Windows Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-06-01 17:12 +0000

csiph-web