Am I or Alexandrescu wrong about singletons?
in [C++]
|
From: Chris M. Thomasson on 5 Apr 2010 17:39 "Andy Venikov" <swojchelowek(a)gmail.com> wrote in message news:hp0avi$nlt$1(a)news.eternal-september.org... > James Kanze wrote: > <snip> >> I'm not sure I follow. Basically, the fence guarantees that the >> hardware can't do specific optimizations. The same >> optimizations that the software can't do in the case of >> volatile. If you think you need volatile, then you certainly >> need a fence. (And if you have the fence, you no longer need >> the volatile.) >> > > Ah, finally I think I see where you are coming from. You think that if > you have the fence you no longer need a volatile. > > I think you assume too much about how fence is really implemented. Since > the standard says nothing about fences you have to rely on a library > that provides them and if you don't have such a library, you'll have to > implement one yourself. A reasonable way to implement a barrier would be > to use macros that, depending on a platform you run, expand to inline > assembly containing the right instruction. In this case the inline asm > will make sure that the compiler won't reorder the emitted instructions, > but it won't make sure that the optimizer will not throw away some > needed instructions. > > For example, following my post where I described Magued Michael's > algorithm, here's how relevant excerpt without volatiles would look like: I am just starting to read some of the posts in this thread, so please tyr to bear with me here... I am wondering which one of Maged Michael's algorithms you are referring to; is it SMR? If so, you have a race condition. > //x86-related defines: > #define LoadLoadBarrier() asm volatile ("mfence") I would probably define `MFENCE' as a `StoreLoad' barrier. [...] > Just to make you happy I defined LoadLoadBarrier as a full mfence > instruction, even though on x86 there is no need for a barrier here, > even on a multicore/multiprocessor. Well, if you are indeed referring to SMR... Then even x86 requires an explicit `StoreLoad' barrier, unless you are using a more "exotic" form of memory synchronization... ;^) -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andy Venikov on 28 Apr 2010 04:19 Anthony Williams wrote: > Andy Venikov <swojchelowek(a)gmail.com> writes: > >> And of course I'll gladly embrace C++0x >> atomic<>... when it becomes available. > > std::atomic<> is available now for some platforms: my just::thread C++0x > thread library provides std::atomic<> for MSVC 2008, MSVC2010 on Windows > and g++4.3, g++4.4 on Ubuntu linux. > > http://www.stdthread.co.uk > > Anthony Actually, I just checked, and it looks like 4.3 still doesn't have atomics... Which kinda makes sense since gcc added C++0x thread support only in 4.4. Andy. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andy Venikov on 28 Apr 2010 04:19 Anthony Williams wrote: > Andy Venikov <swojchelowek(a)gmail.com> writes: > >> And of course I'll gladly embrace C++0x >> atomic<>... when it becomes available. > > std::atomic<> is available now for some platforms: my just::thread C++0x > thread library provides std::atomic<> for MSVC 2008, MSVC2010 on Windows > and g++4.3, g++4.4 on Ubuntu linux. > > http://www.stdthread.co.uk > > Anthony I wasn't aware that atomic<> was available in g++4.3 Scott Meyers' c++0x page lists 4.4 as the first version to support it. I'll post a message in his thread about it. Thanks, Andy. P.S. gcc's page lists atomics as not supported in either of the versions. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andy Venikov on 28 Apr 2010 04:18 Chris M. Thomasson wrote: > "Andy Venikov" <swojchelowek(a)gmail.com> wrote in message <snip> > I am just starting to read some of the posts in this thread, so please > tyr to bear with me here... I am wondering which one of Maged Michael's > algorithms you are referring to; is it SMR? If so, you have a race > condition. No, we're talking about "Simple, fast and practical queues", not SMR. We already talked about this issue when we asked your help in reviewing Tim Blechmann's boost::lockfree implementation back in November '09. Your recommendation was to use Dmitry's Vyukov's xchng-based queue. But the problem with that algorithm was that 1)It was blocking and Tim wanted to have lock-free guarantees and 2)It relies on Intel-specific "lock xchng" that as far as I understand no other vendor implements directly. > > > >> //x86-related defines: >> #define LoadLoadBarrier() asm volatile ("mfence") > > I would probably define `MFENCE' as a `StoreLoad' barrier. Yeah, I explained the reason for LoadLoad being defined as mfence below. I just wanted to make a point that even if mfence instruction is plugged-in, there's no guarantee that optimizer won't remove some important code. > > [...] > >> Just to make you happy I defined LoadLoadBarrier as a full mfence >> instruction, even though on x86 there is no need for a barrier here, >> even on a multicore/multiprocessor. > > Well, if you are indeed referring to SMR... Then even x86 requires an > explicit `StoreLoad' barrier, unless you are using a more "exotic" form > of memory synchronization... > > ;^) Nope, not SMR. Andy. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Anthony Williams on 28 Apr 2010 19:00
Andy Venikov <swojchelowek(a)gmail.com> writes: > Anthony Williams wrote: >> Andy Venikov <swojchelowek(a)gmail.com> writes: >> >>> And of course I'll gladly embrace C++0x >>> atomic<>... when it becomes available. >> >> std::atomic<> is available now for some platforms: my just::thread C++0x >> thread library provides std::atomic<> for MSVC 2008, MSVC2010 on Windows >> and g++4.3, g++4.4 on Ubuntu linux. >> >> http://www.stdthread.co.uk > I wasn't aware that atomic<> was available in g++4.3 > Scott Meyers' c++0x page lists 4.4 as the first version to support it. > I'll post a message in his thread about it. > P.S. gcc's page lists atomics as not supported in either of the versions. std::atomic<> is not shipped with either g++ 4.3 or g++ 4.4. As I stated above, just::thread provides an implementation for the listed compilers. This is a commercial library, available from http://www.stdthread.co.uk Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |