- std::atomic<T>::is_lock_free() - 17 Updates
- some questions - 1 Update
- C++20 is on schedule to be finalized in February - 1 Update
- Where are the exception-objects allocated? - 4 Updates
- parallel merge-sort - 2 Updates
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 13 10:00PM -0800 On 11/12/2019 9:34 PM, Bonita Montero wrote: >> true in some cases and false in others. > I see no logical reason why the machine should determine > at #runtime if an atomic<T> can do lock-free operations. Fwiw, I remember creating some dynamic code wrt checking to see if an x86 had DWCAS or not at runtime. It would set a function pointer to the correct function. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 14 07:26AM +0100 > Fwiw, I remember creating some dynamic code wrt checking to see if an > x86 had DWCAS or not at runtime. It would set a function pointer to the > correct function. And where's the specialization for a native dwcas-datatype of atomic<T>? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 13 10:33PM -0800 On 11/13/2019 10:26 PM, Bonita Montero wrote: >> x86 had DWCAS or not at runtime. It would set a function pointer to >> the correct function. > And where's the specialization for a native dwcas-datatype of atomic<T>? is_lock_free |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 13 10:33PM -0800 On 11/13/2019 10:33 PM, Chris M. Thomasson wrote: >>> the correct function. >> And where's the specialization for a native dwcas-datatype of atomic<T>? > is_lock_free C++11 can handle DWCAS, no problem. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 14 07:50AM +0100 >> And where's the specialization for a native dwcas-datatype of atomic<T>? > is_lock_free Look at the above question ... |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 14 07:51AM +0100 >>> And where's the specialization for a native dwcas-datatype of atomic<T>? >> is_lock_free > C++11 can handle DWCAS, no problem. I'm feeling like talking to Melzzzz. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 13 11:14PM -0800 On 11/13/2019 10:33 PM, Chris M. Thomasson wrote: >>> the correct function. >> And where's the specialization for a native dwcas-datatype of atomic<T>? > is_lock_free Read this: https://groups.google.com/forum/#!original/lock-free/X3fuuXknQF0/Ho0H1iJgmrQJ If the hardware has DWCAS, so does C++11... Either the type is lock-free or not. The method I used wrt dynamic code was well before C++11. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 14 10:43AM +0100 > If the hardware has DWCAS, so does C++11... Either the type is lock-free > or not. > The method I used wrt dynamic code was well before C++11. C++ has no notion of DCAS; everything is transparent. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 14 02:29AM -0800 On Tuesday, 12 November 2019 11:55:02 UTC+2, Bonita Montero wrote: > Can anyone tell me whether std::atomic<T>::is_lock_free() isn't static > as well as constexpr? Having it non-static as well as non-constexpr > doesn't make sense for me. C++ can only use features that its execution environment lets it to. There may be difference between what same operating system provides (in its dynamic runtime library versions). These differences can be side by side available to same executable on same machine ... read up on "dll hell". Further there may be difference what these runtime libraries provide to variables of same type. For example it may depend on how variable of a type is (unavoidably) aligned in memory if it can be accessed without locks atomically. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 14 11:45AM +0100 > runtime libraries provide to variables of same type. For example it > may depend on how variable of a type is (unavoidably) aligned in > memory if it can be accessed without locks atomically. Lock-free Atomic operations don't depend on the operating-system, the dll-hell (weird idea) or the runtime-libraries. And you can be be sure that the specialized atomics that are lock-free are declared to be properly aligned at the class-definition. Do you want to compete with Melzzzz in expertise-unawareness? |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 14 01:11PM +0100 >> doesn't make sense for me. > Take a deep look at the following macros: > https://en.cppreference.com/w/c/atomic/ATOMIC_LOCK_FREE_consts Doesn't help with the question why lock-free-ness of basic atomic -datatypes might be determined at runtime since all these macros are evaluated at compile-time. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 14 07:53AM -0800 On Thursday, 14 November 2019 12:45:48 UTC+2, Bonita Montero wrote: > be sure that the specialized atomics that are lock-free are declared > to be properly aligned at the class-definition. > Do you want to compete with Melzzzz in expertise-unawareness? These were the points raised when C++11 atomics were coined: <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html#DiscussLockFree> Why don't you go and participate in standardization if you are better expert than those dimwits in working group 21. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 14 04:57PM +0100 > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html#DiscussLockFree> > Why don't you go and participate in standardization if you are better > expert than those dimwits in working group 21. This paper doesn't say why is_lock_free can be evaluated at runtime. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 14 08:16AM -0800 On Thursday, 14 November 2019 17:57:44 UTC+2, Bonita Montero wrote: > > Why don't you go and participate in standardization if you are better > > expert than those dimwits in working group 21. > This paper doesn't say why is_lock_free can be evaluated at runtime. Note that universe can not be modified just by typing untruths. :D That is official paper and it continues to say why lock free query function was proposed to be dynamic per object for how long it is archived. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 14 05:26PM +0100 > That is official paper and it continues to say why lock free query > function was proposed to be dynamic per object for how long it > is archived. Quote that statement of the paper. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 14 05:28PM +0100 > Quote that statement of the paper. Ok, you're right: "The proposal provides run-time lock-free query functions rather than compile-time constants because subsequent implementations of a platform may upgrade locking operations with lock-free operations, so it is common for systems to abstract such facilities behind dynamic libraries, and we wish to leave that possiblility open. Furthermore, we recommend that implementations without hardware atomic support use that technique." But that's rather an abstract and untechnical statement. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 14 08:30AM -0800 On Thursday, 14 November 2019 18:27:06 UTC+2, Bonita Montero wrote: > > function was proposed to be dynamic per object for how long it > > is archived. > Quote that statement of the paper. The proposal provides lock-free query functions on individual objects rather than whole types to permit unavoidably misaligned atomic variables without penalizing the performance of aligned atomic variables. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 14 05:24PM +0100 I use a vector to store one or two thread-objects which I emplace_back. I later join the threads. I'd rather like to use a array<thread, 2> but an array<> hasn't a dynamic size ore more precise, a size and a capacity. But I need a size since I can't determine if a thread-object has an attached thread (doing threadObj.getId() != thread::id() doesn't work). So there are two alternatives: 1. Is there a prebuilt class somewhere in boost or wherever that has a static internal capacity but a dynamic size? Something like a more advanced array<T, N>? 2. Is there another way to detect if a thread-object has an attached "physical" thread? |
| Real Troll <Real.Troll@Trolls.com>: Nov 14 12:15PM -0400 <https://herbsutter.com/2019/11/09/trip-report-autumn-iso-c-standards-meeting-belfast/> |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 13 09:58PM -0800 On 11/13/2019 10:44 AM, Bonita Montero wrote: >>> "unspecified storage" isn't a precise answer. >> It is precise answer to question asked. ... > "unspecified" isn't precise. Are you JG? |
| Ian Collins <ian-news@hotmail.com>: Nov 14 08:11PM +1300 On 14/11/2019 08:41, Scott Lurndal wrote: >> h details are far easier to find in such specialized forums, rather than in= >> this one. > Or BM could simply download the compiler sources and figure it out. Rude trolls don't do that.. -- Ian. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 14 12:42PM +0100 On 13.11.2019 17:59, Bonita Montero wrote: > allocation might fail? And remember that these objects even have > to live longer than a thread because you might refer to it by > an std::exception_ptr. For string data you can leverage the internal special immutable string class by using `std::runtime_error` or a derived class. It can of course throw when the original exception is created, but after that it's guaranteed that copying does not throw: C++17 §21.8.2/2: "Each standard library class T that derives from class exception shall have a publicly accessible copy constructor and a publicly accessible copy assignment operator that do not exit with an exception." For other data you have to ensure this guarantee yourself. A reasonable approach is to minimize the amount of other data in an exception. - Alf |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 14 01:07PM +0100 > "Each standard library class T that derives from class exception shall > have a publicly accessible copy constructor and a publicly accessible > copy assignment operator that do not exit with an exception." 1. I'm talking about the storage for the exception-object itself; this isn't allocated by your own code but the rundime-library. 2. I just posted my parallel merge-sort-algorithm. It gathers the exceptions which might occur in the sorting-threads in a single pre-allocated vector of exception_ptr's and moves this vector inside the exception which might be thrown later. If I would provide a copy-costructor or assignment-operator, this vector would be copied and an exception might get thrown. This might occur when you don't catch the exception by reference (I don't see any reason to catch exception-objects by value anyway). So there are good reasons to not to provide both. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 14 06:24AM +0100 There's stable_sort( execution::parallel_policy(), ... ) to have a parallel stable sort, usually realized via merge-sort. I wrote my own parallel merge-sort implementation to check whether I get a better performance. On Windows with VC++ 2019 my merge-sort takes about 35% less time. I'd like to see results from the libstdc++ library as well as LLVM's libc++. You can select between my merge -sort and the standard library's merge-sort via BUILTIN_PAR. And please define NDEBUG when compiling to strip the assertions. //#define BUILTIN_PAR #include <iostream> #include <random> #include <limits> #include <algorithm> #include <cassert> #include <iterator> #include <cstdlib> #include <chrono> #include <cstdint> #include <thread> #include <functional> #include <exception> #include <mutex> #if defined(BUILTIN_PAR) #include <execution> 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment