Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #69716 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2019-11-12 10:54 +0100 |
| Last post | 2019-11-14 11:45 +0100 |
| Articles | 11 on this page of 91 — 9 participants |
Back to article view | Back to comp.lang.c++
std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 10:54 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 11:24 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 14:11 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 14:39 +0100
Re: std::atomic<T>::is_lock_free() Bo Persson <bo@bo-persson.se> - 2019-11-12 16:46 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 17:40 +0100
Re: std::atomic<T>::is_lock_free() Bo Persson <bo@bo-persson.se> - 2019-11-12 20:23 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-12 15:21 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:09 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 06:34 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 22:00 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 07:26 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 22:33 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 22:33 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 07:51 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 07:50 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 23:14 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 10:43 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-12 15:14 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 13:11 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-14 07:53 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 16:57 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-14 08:16 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 17:26 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 17:28 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-14 08:30 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 17:33 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:41 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-15 09:31 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-15 12:59 -0800
Re: std::atomic<T>::is_lock_free() scott@slp53.sl.home (Scott Lurndal) - 2019-11-15 21:47 +0000
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-15 13:56 -0800
Re: std::atomic<T>::is_lock_free() scott@slp53.sl.home (Scott Lurndal) - 2019-11-16 18:07 +0000
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-16 13:55 -0800
Re: std::atomic<T>::is_lock_free() scott@slp53.sl.home (Scott Lurndal) - 2019-11-16 22:13 +0000
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-16 18:40 -0800
Re: std::atomic<T>::is_lock_free() James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-17 18:39 -0500
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-17 20:59 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-17 21:00 -0800
Re: std::atomic<T>::is_lock_free() James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-18 08:25 -0500
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-18 18:24 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-15 13:59 -0800
Re: std::atomic<T>::is_lock_free() Ian Collins <ian-news@hotmail.com> - 2019-11-16 11:08 +1300
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-15 15:39 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-16 07:22 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-16 08:06 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-16 17:13 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-16 08:26 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-16 19:27 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-16 10:37 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-16 19:47 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-16 11:34 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 09:17 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 01:52 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 11:23 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 03:22 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 14:20 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 06:39 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 15:49 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 22:54 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-18 08:03 +0100
Re: std::atomic<T>::is_lock_free() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 15:39 -0800
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-28 16:33 -0800
Re: std::atomic<T>::is_lock_free() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 22:48 -0800
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2020-01-11 00:24 -0800
Re: std::atomic<T>::is_lock_free() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-14 07:16 -0800
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2020-01-14 08:55 -0800
Re: std::atomic<T>::is_lock_free() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 02:01 -0800
Re: std::atomic<T>::is_lock_free() James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-21 06:00 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 15:58 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-17 21:01 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-18 07:00 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 22:45 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-18 07:52 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-18 08:10 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 23:23 -0800
Re: std::atomic<T>::is_lock_free() Ian Collins <ian-news@hotmail.com> - 2019-11-18 20:26 +1300
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 23:05 -0800
Re: std::atomic<T>::is_lock_free() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 15:44 -0800
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-28 16:43 -0800
Re: std::atomic<T>::is_lock_free() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-11 06:41 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:33 -0800
Re: std::atomic<T>::is_lock_free() Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-14 19:08 +0000
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 20:12 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:35 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:32 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:37 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-15 09:32 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-15 13:06 -0800
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-14 02:29 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 11:45 +0100
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-11 06:41 -0800 |
| Message-ID | <86h8122gyd.fsf@linuxsc.com> |
| In reply to | #70102 |
Tiib writes: > On Friday, 29 November 2019 01:45:04 UTC+2, Tim Rentsch wrote: > >> Tiib <ootiib@hot.ee> writes: >> >>> On Monday, 18 November 2019 08:52:27 UTC+2, Bonita Montero wrote: >>> >>>>>>> Nonsense. What is aligned or misaligned is up to compiler >>>>>>> itself to decide. >>>>>> >>>>>> Wrong. If you pack your members tighter than alignof(membertype) >>>>>> allows this is not conforming. >>>>> >>>>> That is a bald and groundless assertion. >>>> >>>> "Object types have alignment requirements (6.9.1, 6.9.2) which place >>>> restrictions on the addresses at which an object of that type may be >>>> allocated. ... >>> >>> ... >>> The alignment required for a type might be different when it is used >>> as the type of a complete object and when it is used as the type of >>> a subobject. >>> ... >> >> No it cannot. Refer to n4659, section 6.11, paragraph 1. Note >> in particular the last sentence, which says in part (with my >> emphasis added): >> >> An object type imposes an alignment requirement on EVERY >> OBJECT of that type >> >> There is no provision for the alignment varying according to >> whether the object is a complete object or a subobject. > > Very next paragraph #2 says that: > "The alignment required for a type might be different when it is used > as the type of a complete object and when it is used as the type of > a subobject." So it does. Interesting. (It happens that in the document I consulted, these two paragraphs were split by a page boundary, which makes the second paragraph easy to miss. It would be better to have the two conflicting statements be in a single paragraph.) I note that the example relies on virtual base classes. This explains why the special case is there. ISTM that having the two cases be different is poorly thought out, as it makes the notion of alignment be almost meaningless. But, that's C++ for ya.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-14 13:33 -0800 |
| Message-ID | <qqkh83$175q$4@gioia.aioe.org> |
| In reply to | #69732 |
On 11/14/2019 8:16 AM, Öö Tiib wrote: > On Thursday, 14 November 2019 17:57:44 UTC+2, Bonita Montero wrote: >>>>> 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. >> >>>> 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? >> >>> 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. >> >> 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. > BM is JG. am 99.98... percent sure....
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-11-14 19:08 +0000 |
| Message-ID | <KChzF.23292$DK1.369@fx38.am4> |
| In reply to | #69716 |
On 2019-11-14, Bonita Montero <Bonita.Montero@gmail.com> wrote: >> 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. > > 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? Do you know what lock free means? -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-14 20:12 +0100 |
| Message-ID | <qqk8ug$uiv$1@news.albasani.net> |
| In reply to | #69740 |
>>> 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. >> 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? > Do you know what lock free means? You're the last who knows that.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-14 13:35 -0800 |
| Message-ID | <qqkhbe$175q$5@gioia.aioe.org> |
| In reply to | #69741 |
On 11/14/2019 11:12 AM, Bonita Montero wrote: >>>> 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. > >>> 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? > >> Do you know what lock free means? > > You're the last who knows that. > You are quite a character. Watch out Melzzzz, the Cruel Puppet BM is very strange! https://www.thezorklibrary.com/history/cruel_puppet.html CRUEL PUPPET Few creatures are more despised than the cruel puppet, one which uses its power not for good, evil or profit, but simply to hurt people's feelings. Staunch monarchs have been reduced to tears by these merciless shapeshifters; for it attacks by twisting itself into unflattering caricatures of its opponents, accompanied by jeers, rude noises and shocking accusations--which include the recital of nightly personal habits in excruciating detail, accusing its adversary's mother of shocking improprieties, reminding of weight gain, etc. They have also been known to practice existential put downs. "You're so ugly you're probably the creation of an unseen master who is controlling and shaping the world around you. Nothing is real and nothing you do will have any lasting effect on those around you. Welcome to the dark night of your soul" is but one example. More often, however, they just insult your knees. Insulting the cruel puppet in return is futile, for it feeds off of them. Straining to ignore these verbal attacks is the only known defense. Residents of Gurth City were warned during the mid-tenth century to keep away from the Forest of Youth, as it was known home to cruel puppets. During the Great Monster Uprising of the Second Age of Magic, cruel puppets were reported in the following regions: The abandoned Casino of Port Foozle, The Southern Wastes, The Coast Road near Borphee, Pheebor, Forest of Youth, Gurth Woodland Trail, the Lost Castle of Y'Syska, Crab Island, Egreth Castle, The Glass Maze, Bozbarland, Largoneth Castle, and the G.U.E. Tech Training Grounds in the Ethereal Plane of Atrii. Many perched in trees and other high and covert corners, raining handfuls of exploding chestnuts down upon luckless adventurers.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-14 13:32 -0800 |
| Message-ID | <qqkh5g$175q$3@gioia.aioe.org> |
| In reply to | #69716 |
On 11/14/2019 2:45 AM, Bonita Montero wrote: >> 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. > > Lock-free Atomic operations don't depend on the operating-system, Are you sure about that? Remember that one can implement a pure std c++11 atomic lib using semaphores. Windows has some interesting checks wrt memory violations wrt its lock-free stack. Its all in the OS. > 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?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-14 13:37 -0800 |
| Message-ID | <qqkhfh$175q$6@gioia.aioe.org> |
| In reply to | #69744 |
On 11/14/2019 1:32 PM, Chris M. Thomasson wrote: > On 11/14/2019 2:45 AM, Bonita Montero wrote: >>> 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. >> >> Lock-free Atomic operations don't depend on the operating-system, How can you say that? How do you know what the os is doing?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-15 09:32 +0100 |
| Message-ID | <qqlnrg$3ed$2@news.albasani.net> |
| In reply to | #69744 |
>> Lock-free Atomic operations don't depend on the operating-system,
^^^^^^^^^^^^^^^^
> Are you sure about that? Remember that one can implement a pure std
> c++11 atomic lib using semaphores. ...
Wat of the underlined wording above don't you unterstand?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-15 13:06 -0800 |
| Message-ID | <qqn40l$18u3$1@gioia.aioe.org> |
| In reply to | #69750 |
On 11/15/2019 12:32 AM, Bonita Montero wrote: >>> Lock-free Atomic operations don't depend on the operating-system, > ^^^^^^^^^^^^^^^^ >> Are you sure about that? Remember that one can implement a pure std >> c++11 atomic lib using semaphores. ... > > Wat of the underlined wording above don't you unterstand? > Ideally lock-free atomic operations should boil down to pure hardware instructions. Take a 32 bit x86. The atomic operation of a double word should be using CMPXCHG8B. However, we cannot know what some operating system is doing. Like I said, the simple lock-free stack on Windows uses some funky OS support.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-14 02:29 -0800 |
| Message-ID | <935f62b5-e136-436c-9853-5f80ce30c553@googlegroups.com> |
| In reply to | #69716 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-14 11:45 +0100 |
| Message-ID | <qqjb8g$8im$1@news.albasani.net> |
| In reply to | #70134 |
> 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. 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?
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c++
csiph-web