"Bad" I would say means you can still achieve your task.
I was presented with over sixty download links, and not being an idiot or someone to be taken for a ride, I refused to go along with it, and that means the UI is not bad but failed.
What's more, it OBVIOUSLY failed.
There's no way a single person at Amazon could have genuinely sat there and thought, "yes, this, THIS is it, THIS is the right way to make this page", not, that is, if their goal was the user actually getting hold of their data.
I've been trying for over two years to get my data from Amazon.
I eventually got to a point where Amazon provided a web-page, which has no less than sixty-two download links on, each of which would have to be manually operated.
It's properly tantamount to obstruction.
After finally reaching this point, Support were arrogant and high-handed - "We will not do any more than we have. We look forward to seeing you on Amazon in the future."
I still do not have my data.
I tried to start the process off a second time, but it went nowhere. I chased it, and then had some very disconnected and confusing responsese from Support (email from some random guy in Support who by the looks of it had been told to email me, but neither he had been told what for, nor I that it would happen).
I've not spent more time on it since then.
I stopped using Amazon about two years ago, because I've come to the view that the stories about how Amazon treats warehouse staff are accurate.
I want to get my personal data, so I can close the account.
Amazon of course refuse point blank (in the usual, slimey, support-talking-past-you way) to delete any personal data, so all you can do is delete the account and hope in the end Amazon expire the data.
> I eventually got to a point where Amazon provided a web-page, which has no less than sixty-two download links on, each of which would have to be manually operated.
> I still do not have my data.
> I want to get my personal data
Is there a good reason why you don't take the three minutes to click the 62 download links?
Firefox to my eye jumped the shark a long, long time ago, when they took to using deliberate deception during the install process to get people to sign up to a Mozilla account.
Pretty much everything they've introduced for years I've not wanted or disliked.
The saving grace has been that pretty much everything can be turned off in about::config.
I may be wrong, but I think Moz has become a typical larger company, wholly divorced from its users, unable to know what users want, let alone respond.
What Moz as a large company wants is really completely different to what users want, and a unique tracking ID is a shining example of this.
I'll be using Tor, but I my secondary browser now has to change, as this is intolerable.
I may be wrong, but I don't see this working in theory.
The basic problem is that for any physical core, there is no guarantee that any writes will ever be seen by any other core (unless the necessary extra magic is done to make this so).
(There's a matching problem when reading, too, in that in theory writes made by another core can be never seen by the reading core, even if they have reached the domain covered by cache coherency, unless the necessary extra magic, etc.)
So here with this code, in theory, the writes being made simply are never seen by another core, and so it doesn't work.
As it is, in practise, writes typically make their way to other physical cores in a reasonably short time, whether or not the extra magic is performed; but this is not guaranteed. Also of course the ordering of the emergence of those writes is not guaranteed (although on some platforms, additional guarantees are provided - Intel is particular generous in this regard, and performance suffers because of it).
> The basic problem is that for any physical core, there is no guarantee that any writes will ever be seen by any other core (unless the necessary extra magic is done to make this so).
They're using atomic read/writes with sequential-consistency.
This means that the compiler will automatically put memory-barriers in the appropriate locations to guarantee sequential-consistency, but probably at a significant performance cost.
The implementation is likely correct, but its the slowest performance available (seq-cst is the simplest / most braindead atomic operation, but slowest because you probably don't need all those memory barriers).
I'd expect that Acq-release style barriers is possible for this use case, which would be faster on x86, POWER, and ARM systems.
> They're using atomic read/writes with sequential-consistency.
In the C11 code? I'm not up to speed with that version of the spec, but unless there is behaviour invoked by the use of _Atomic, the code looks to me to be performing normal, non-atomic read/writes.
Another reply says there are full barriers being automatically used, but that doesn't address the problem I've described.
> but unless there is behaviour invoked by the use of _Atomic
That is the behavior invoked by "atomic".
The general gist is that "manual" read/write barriers were too difficult to think about and led to bugs. Instead of having the programmer put the read/write barriers in the correct locations, modern compilers put a type-specification on variables... and then its the compiler's job to put the barriers in the correct location.
This turned out to be necessary, because the compiler's optimizer kept rearranging code (!!!) around memory barriers anyway. So the "compiler" needs to participate in any of the barriers, especially at higher levels of optimization (-O3 rearranges a lot of code). If the compiler needs to participate, you might as well have the compiler handle the placement of those barriers.
"Atomic" variables by default will be sequentially-consistent (ie: the _maximum_ use of memory barriers for _maximum_ levels of consistency).
You're talking here about memory barriers, but I was asking if atomic writes are in use.
Atomic writes have nothing to do with memory barriers. On modern platforms atomic writes are available without memory barriers of any kind.
Memory barriers do not cause events to become visible.
Only atomic writes do this; and so the question is not whether barriers are in use due to _Atomic, but whether atomic writes are in use due to the use of _Atomic.
_Atomic types can be read-modified-written atomically (if using a compound-assignment operator), or the postincrement/pre-increment operations.
In these circumstances, the memory-barriers used for those atomic-operations will be of the sequentially-consistent memory model.
------
So yes, that "++*barrier" operation is read-modify-write atomically AND with memory-barriers in sequential-consistency style
-----
I don't believe that "atomics" are enough to solve this problem. At a minimum, I expect acq-consume to be required (not that acq-consume model even works in practice... so acq-release for today's compilers). That's why I'm still talking memory model / fences here.
Not only is an atomic operation required, but so too is the "publishing" of this information needing to happen in the proper order. Fortunately, C11's _Atomic implementation solves both issues.
> Built-in increment and decrement operators and compound assignment are read-modify-write atomic operations with total sequentially consistent ordering (as if using memory_order_seq_cst). If less strict synchronization semantics are desired, the standard library functions may be used instead.
This is true in a strict sense, but essentially no concurrent code works if you don't assume that writes become eventually visible to all other threads.
Consider something basic like implementing a mutex: once a thread unlocks a mutex, it is possible in theory that no other thread _ever_ sees the mutex as unlocked, and spin on it forever, but such a system would be useless.
In practice, general purpose CPUs have writes become visible as fast as possible.
You won't find this behavior defined strictly in memory models, because how can you? These talk only about ordering and eschew things like "global clocks" and even if you had such a clock, how are you going to put a numerical bound on the delay?
Most will leave it as a quality of implementation issue and specify that writes become visible "eventually" if they say anything at all.
Barriers only influence the order in which events become visible if and when they DO become visible.
Barriers say nothing about whether or not events actually do become visible; and it may be that they never do (if the necessary magic is not performed, etc).
You mention an atomic increment. I don't see atomic increments this in the C11 code, but I'm not up to speed with that version of the specification.
(Note that an atomic increment will solve the write-side problem, but not the read-side problem. The reader must still use a read barrier; but if there's an implicit full barrier, then that's being done.)
> The fact that another thread sees the incremented value implies that that thread will see all stores that happened-before that incremented value.
Firstly, if the writer has used no barriers, writes can emerge in any order (and may never emerge at all, anyway, even if barriers were used). Secondly, if the reader has not used barriers, then even if writes have been written in some given order, the reader will by no means observe that order.
> A fence or atomic operation guarantee that a store will be visible globally in a finite amount of time
A fence does NOT guarantee this. A fence controls and only only controls order of events. It has NO influence on whether events actually emerge. An atomic operation does, but this only solves the write-side of the problem; the reader still needs to issue a read barrier to guarantee seeing atomically written values.
An atomic write will need to be issued, and on the face of it, that C11 code is not issuing an atomic write. I could be wrong, but I would expect a particular function or macro to be used for an atomic write, and when it is not, you have normal writes.
> So all operations on _Atomic variables in C11 are implicitly atomic
I may be wrong, but I would be shocked if this was so.
I think you may be mixing up non-tearing writes as opposed to atomic writes, which are performed using either cache-line locking (Intel) or exclusive reservation granules (everyone else) and as such require the employment of a specific mechanism to achieve (typically a macro or function, which leads to the use of the particular special instructions for atomic writes).
The overhead of an atomic write is very large, and it is often not needed. It would make no sense for every write (to an _Atomic type) to be atomic.
The standard does guarantee that all the operations on _Atomic variables are indeed atomic and, by default, sequentially consistent. Standard library functions like atomic_load can be used to specify more relaxed ordering.
As per intel docs, all aligned stores and loads are atomic with additional release and acquire semantics. XCHG (which is somewhat expensive) is used for SC stores, but plain loads still suffice for SC loads.
On other architectures load and stores are usually at least atomic, although with only relaxed ordering semantics.
Normally non-tearing + cache coherence is all that is required for relaxed atomic load/stores. You are confusing with general RMW that require specialized instructions on intel or ll/sc on RISCs (although ARM did add a bunch of specialized atomic instructions as well). To be pedantic, as far as I know, Intel doesn't lock the cacheline in any special way during an atomic RMW, it simply delays the read until all preceding stores have been flushed from the store buffer, then, if it has successfully acquired the line in exclusive mode, executes the load+store within whatever minimum exclusive cache hold period guaranteed by the coherence protocol. Acquiring a cacheline in exclusive mode is not specific to atomic RMWs but applies to any store and it is not really a lock as it can be taken away at any moment (i.e. the cc arbiter guarantees forward progress of the system as whole).
> As soon as the land of any country has all become private property, the
landlords, like all other men, love to reap where they never sowed, and
demand a rent even for its natural produce.
as well as
> They [landlords] are the only one of the three orders whose revenue costs them neither labour nor care, but comes to them, as it were, of its own accord, and independent of any plan or project of their own.
I just don’t think that argument is viable. They provide ongoing highly valued services people choose to pay for. Advertising for Google and Facebook, retail and hosting services for Amazon, physical products and online services for Apple, etc. They employ hundreds of thousands of people, are constantly updating and extending their products and services. That’s all serious work done by actual people.
I’m not justifying everything they do, or all their business practices, but if these companies didn’t provide those services someone else would. There’s a genuine need.
"Parasitic" can be descriptive? I means roughly someone that takes from a system without giving to or benefiting it.
Parasitic does have a fairly strong negative connotation, and Smith doesn't literally use the word, but those two passages do seem to have somewhat of a negative connotation to them, to my reading.
I am quite sure the discourse on "rent seeking activities" come with a negative connotation in the wealth of nations. (forgive me if I am wrong, it is some years ago I read it)
I was speaking once to a Dutch acquaintence, who told me that in his economics class at Uni, they were taught Smith was in favour of large State subsidies...!
Large state subsidies in what context? That's a rather critical point. Smith certainly envisioned a significant role for government, even though he was also critical of much government intervention.
I don't specifically remember that form Wealth of Nations, I know he argued against some cases, but he did argue for all kinds of other intervention for sure.
"It is not very unreasonable that the rich should contribute to the public expense, not only in proportion to their revenue but something more than in that proportion."
Smith very much supported the existence of the state for several purposes. If I recall correctly they are things pretty non controversial like defense, infrastructure, property rights, regulations that enable markets to operate effectively (providing necessary transparency so that people can make informed choices, protections against monopolies and rent seeking behavior). He correctly identifies that while some regulations are necessary, some will seek to use them to protect their own position, ie regulatory capture.
Overall, his message is decidedly pro freedom and against top down economic planning and intervention. People are naturally self interested, and enabling them to voluntarily trade with others as they see fit enhances the life of each partner of the trade. Scale that up and society advances itself with an centralized arbiter to guide it.
As for taxes, the reason he felt that the rich should pay more is because they derive the most benefit from the existence of the state.
Apologies if I came across in any way patronizing, my intent was to add some details for others in the context of Smith's views on the role of the state, which I felt were lacking in the wider thread in general. Your original comment sparked those thoughts for me, which is why I replied there. My comment was not intended for you personally so much as for the wider audience.
If my etiquette was at all inappropriate I apologize.
