- std::atomic<T>::is_lock_free() - 9 Updates
- Guess what, biotches? Daddy's home! - 1 Update
- Regal eagle / American cloud - 4 Updates
- Program that solve infinity problems - 1 Update
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 12 10:54AM +0100 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. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 12 11:24AM +0100 > 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. Someone on Stack Oveflow told me this: an atomic value might be un- aligned so that access might be not atomic. So the compiler can't say at compile-time whether the access can be atomic. But there's a static constexpr bool called std::atomic<T> ::is_always_lock_free. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 12 02:11PM +0100 > aligned so that access might be not atomic. So the compiler can't say > at compile-time whether the access can be atomic. But there's a static > constexpr bool called std::atomic<T> ::is_always_lock_free. On the other side I can't believe this because the language says that unaligned accesses have undefined behaviour; so there must be another reason for the distinction between is_lock_free and is_always_lock_free. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 12 02:39PM +0100 > On the other side I can't believe this because the language says that > unaligned accesses have undefined behaviour; so there must be another > reason for the distinction between is_lock_free and is_always_lock_free. Although I was pretty confident that C++ doesn't make the decision between is_lock_free and is_always_lock_free because of the alignement I wrote a little program to check this. I've got installed Visual Studio with compilers for the Windows-platforms for ARMv8-CPUs. And ARMv8 is able to do unaligned memory-accesses but compare & exchange etc. is mandated to be aligned. So I thought that when I call is_lock_free on a pointer to an atomic is_lock_free wouldn't simply return true of for each atomic but only if the atomic is properly aligned. So I wrote a little function to check this: #include <atomic> #include <cstddef> bool isLockFreeAtomic( std::atomic<std::uint64_t> *a64 ) { return a64->is_lock_free(); } When I compile this with assembly-output I get the following code: |?isLockFreeAtomic@@YA_NPAU?$atomic@_K@std@@@Z| PROC movs r0,#1 |$M12| bx lr ENDP So it's like I expected: the runtime-lib doesn't check the pointer. So there must be another reason why there's a decision between is_lock_free and is_always_lock_free. |
| Bo Persson <bo@bo-persson.se>: Nov 12 04:46PM +0100 On 2019-11-12 at 14:39, Bonita Montero wrote: > So it's like I expected: the runtime-lib doesn't check the pointer. > So there must be another reason why there's a decision between > is_lock_free and is_always_lock_free. It might just be for historic reasons. In C++14 we only have the function and it is speced: Returns: True if the object's operations are lock-free, false otherwise. It said nothing about whether different objects of the same type always returned the same value. In C++17 we also got is_always_lock_free, where *always* is important, and the function is now supposed to return the same value (says a non-normative comment...). Bo Persson |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 12 05:40PM +0100 > Returns: True if the object's operations are lock-free, false otherwise. > It said nothing about whether different objects of the same type always > returned the same value. There's no logical reason why they should. |
| Bo Persson <bo@bo-persson.se>: Nov 12 08:23PM +0100 On 2019-11-12 at 17:40, Bonita Montero wrote: >> It said nothing about whether different objects of the same type >> always returned the same value. > There's no logical reason why they should. So therefore we now also have the member is_always_lock_free. :-) In my previous post I a bit hastily stated that the functions always return that value, but in reality that is only true if the value *is* true. When is_always_lock_free is false, the functions just *might* return true in some cases and false in others. Just to make it more complicated, there are also macros for some types, like ATOMIC_INT_LOCK_FREE (which can have the value "sometimes lock free" :-). Bo Persson |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 12 03:14PM -0800 On 11/12/2019 1:54 AM, 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. Take a deep look at the following macros: https://en.cppreference.com/w/c/atomic/ATOMIC_LOCK_FREE_consts |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 12 03:21PM -0800 On 11/12/2019 11:23 AM, Bo Persson wrote: > Just to make it more complicated, there are also macros for some types, > like ATOMIC_INT_LOCK_FREE (which can have the value "sometimes lock > free" :-). Indeed! The atomic types are allowed to be created using locks or even obstruction free constructs: All lock-free is obstruction free, but not all obstruction free is lock-free... ;^) |
| Anonymous <anonymous@anon.net>: Nov 12 05:17PM -0500 Obama and the atheist CIA wake each day and ask, "How can we fuck God, today? I know! We'll make nuns perform abortions. We make homos dance naked in Russian churches in front of old church ladies. Isn't that hilarious? We'll make a complete mockery of marriage because, after all, niggers don't have fathers and that's not fair. My wife, Michelle, wants no cupcakes for school birthdays because of single moms. We'll make God hated... just for pedophiles and crazy insane sand-niggers. We'll drink fetus soup with the Queen and celebrate the end of births. Having children is pedophillic. We'll make every five year old African girl learn how to put on a condom. We'll make churchs no longer tax exempt. <Giggle> We'll make all the conservative sons into liberal atheist homos. <Giggle> Will bring in Mexicans to ensure democratic votes. The USA will be a slum like Mexico but I don't care. On second thought... I love white people! Come back! How come white people don't have kids? Oh yeah, we made the white people greedy, coveting the wealth of the rich." The IRA is like the NRA, but for computers. The CIA wants all code in the cloud under their lock and key. They want to ban compilers and make people think HTML is computer programming. They want to evaporate desktops so you have no local computer, just massive cloud computers. |
| woodbrian77@gmail.com: Nov 11 10:33PM -0800 I installed gcc10 on a FreeBSD 12.1 machine. That machine also has gcc9.2 on it. When I try to use g++10, I get an error that it cannot execute 'cc1plus' execvp: No such file or directory . I found a cc1plus file under a gcc9 directory, but that's the only version I found under /usr/local. I want to use span so am trying to get g++10. The only idea I have is to do something like pkg remove gcc9 but kind of doubt that would help. I have a version of clang on the machine that I can use, but just thought I'd see if I could get gcc10 to work. Any ideas? Thanks. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 11 11:38PM -0800 On 11/4/2019 2:03 AM, David Brown wrote: > I learned a number of things from that discussion, and had some of my > misconceptions corrected. It was, IMHO, a good example of how Usenet > threads are supposed to be (unlike this one). 100% Agreed. A medium for nice correspondence... Usenet? ;^) |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 11 11:39PM -0800 On 11/11/2019 11:38 PM, Chris M. Thomasson wrote: >> misconceptions corrected. It was, IMHO, a good example of how Usenet >> threads are supposed to be (unlike this one). > 100% Agreed. A medium for nice correspondence... Usenet? ;^) Well, it takes two to tango, and if each person is nice, and able to not go crazy, well... Yes, Usenet is nice. |
| woodbrian77@gmail.com: Nov 12 08:26AM -0800 > but kind of doubt that would help. > I have a version of clang on the machine that I can use, but just > thought I'd see if I could get gcc10 to work. Any ideas? Thanks. I got it working by using the span header from gcc10 with gcc9. |
| wyniijj@gmail.com: Nov 11 07:41PM -0800 I had just written a short article, which is also a programming plan about how to handle infinity. The basic idea (except to make known) is that NUMBER IS OPERATION. class ANum { // number is a tree node int m_optype; int m_arg1; int m_arg2; }; This article already defy what most of us are familiar with, which made me a bit uneasy. What I know I did not know well is 1. Is the plan mathematically correct? 2. what else the math (number system) is out there I missed 3. typo and wording errors. 4. what kind of question can we ask, particularly typed by keyboard, and to what extend the terminal output we can accept. We do not want the whole tree dumped. 5. skill of search tree pruning required. 6. what is the result can we expect, from the article?. Understanding the essence of the article may take time, especially those believe 0.999...=1 or lim(n->∞){1/n}=0, or not yet cared about. ---------- The article is short but I think is still a bit too long to put here So I just put snipped paragraphs. The full article is file Infinity.txt can be found in the main directory: https://sourceforge.net/projects/cscall/files/libwy-0.59.3.tgz/download ...[Snipped] +------------+ | Defining ∞ | +------------+ From the initial understanding of [Prop1], there are many infinities. Some trial analysis exhibits that there might exists a base infinity. On the other hand, facing an equation like e=(1+1/∞)^∞ (or similar equations), we must ask: Is that 'finite' value e unique? I believe we would like it unique. Therefore, ∞ must be unique as well. So, adding ∞ to the algebraic system is doable. Definition of ∞: 1. ∀n∈ℕ, n<∞ 2. The multiplicative inverse of ∞ is 1/∞, the additive inverse is -∞ The benefit of handling ∞ this way is 1.safe guaranteed 2.self-contained, not much is needed to explain. What is left should probably be interpretation issues. --------------------------------------------------- Test1: Let f(x)=∑(n=0,x){n} = x*(x+1)/2 // sum of natural numbers g(x)=∑(n=0,x){2n}= x*(x+1) // sum of even numbers h(x)=∑(n=0,x){2*n+1} = (x+1)^2 // sum of odd numbers g(x)+h(x)=∑(n=0,x){(2*n)+(2*n+1)}= =∑(n=0,x){4*n+1} =x*(x+1)+(x+1)^2=(x+1)*(2*x+1) // sum of odd and even // numbers // Using ∞ f(∞)=∞*(∞+1)/2 // sum of natural numbers g(∞)=∞*(∞+1) // sum of even numbers h(∞)=(∞+1)^2 // sum of odd numbers, h(∞)-g(∞)=∞+1 g(∞)+h(∞)= // sum of odd and even =∑(n=0,∞){(2*∞)+(2*∞+1)}= ∞*(∞+1)+(∞+1)^2=(∞+1)*(2*∞+1) =∑(n=0,∞){4*∞+1} =(∞+1)*(2*∞+1) // 1+5+9+...+(4*∞+1) ∴ The sum of natural numbers is not equal to the sum of odd numbers plus the sum of even numbers (there are ambiguity issues) ...[Snipped] +------------------------+ | Modifying Peano axioms | +------------------------+ The sub-goal of the text so far is teaching computers a way to help us handle math problems. For now, the main issues are ∞ and infinite progressions. Therefore, Peano axioms need be modified: 1. 0∈ℕ, INT_MAX∈ℕ // INT_MAX is the maximal number in ℕ. This number is // arbitrarily large but can be reached by counting // and can be viewed as a pseudo-infinity. Axiom 3a has // explained this point. Programs with INT_MAX set to // greater than S^63(0)=63 should work fine for many // infinity problems. // [Note] INT_MAX can in theory be a finite value that // can never be reached in reality, e.g. Axiom 3a // can generate (allow) the successor of any given // 'maximum', is still not INT_MAX. ∞∈𝔸 2. ∀x∈ℕ∪𝔸, x=P(S(x)) // S(x) represents the succesor function of x, P(x) the // predecessor function of x. P and S are inverse function // of each other. Uniqueness is implied by the definition // of function. 3a. ∀x∈ℕ if(x==INT_MAX) S(x)=∞-INT_MAX // Range jump. ∞-INT_MAX∈𝔸 else S(x)∈ℕ 3b. ∀x∈𝔸 if(x==∞-INT_MAX) P(x)=INT_MAX // Range jump. ∞-INT_MAX is the smallest // (non-fractional) number in 𝔸. else P(x)∈𝔸 // S(∞)∈𝔸 holds as well, just not yet used 4. Others are roughly the same as the average definition of Peano axioms. No need to be completely formal for now. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment