Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #1511
| Newsgroups | comp.programming.threads |
|---|---|
| Subject | Re: Thread scaling in Windows |
| From | Paavo Helde <myfirstname@osa.pri.ee> |
| References | <XnsA1CFD0BECDBADmyfirstnameosapriee@216.196.109.131> <51a7c499$0$6565$9b4e6d93@newsspool4.arcor-online.net> <XnsA1D1132254871myfirstnameosapriee@216.196.109.131> <4fegq89mvs3l3k3apo1onv40ls0t6av4vh@4ax.com> |
| Organization | PKI |
| Message-ID | <XnsA1D2CE07A916Bmyfirstnameosapriee@216.196.109.131> (permalink) |
| Date | 2013-06-01 12:15 -0500 |
Robert Wessel <robertwessel2@yahoo.com> wrote in news:4fegq89mvs3l3k3apo1onv40ls0t6av4vh@4ax.com: > > Memory management can be an area of quite high lock contention, > particularly in C++ code with many "new"s being executed. Plugging > something like SmartHeap into your application is a simple fix if > that's a problem. I'm suspecting more and more that the memory allocator might be the culprit indeed. The screenshot of task managers at the SmartHeap home page exactly matches our experience. And we have lots and lots of small memory allocations. > I'm not sure what boost::mutex is doing internally these days, but I > think they're doing their own lock-free structure plus a Windows event > object. If they're not sharing that event object between mutexes, and > you're creating these mutex objects at a rapid rate, you could have > quite high overhead from the creating of the event objects. From what I gather from the Boost code they are creating event objects only in case of contention (a lock does not succeed). Anyway, our objects which are thread-shared are typically long-living so it shouldn't matter. Cheers Paavo
Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar
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