Shameless plug: https://lwn.net/Articles/844224/ is in my opinion exactly the parts that are missing from the book that the author criticizes. I focus on how threads synchronize, independent of the actual primitives you use, and then explain how that synchronization is usually realized.
I can not give you thi final feedback at the moment, I only breefly looked through the articles for not.
The first ones are very accessible (given my prior lnowledge of lamport clocks and happens before as in Java memory model), the later ones I am currently not sure are very clear.
But are easier than the docs I used when first approached this topic in the past, like Documentation/memory-barriers.txt and the Doug Lea's texts.
If you mean memory barriers in terms of concurrency, it's just a primitive for concurrency that counts downward atomically once per participant (e.g. a group of threads) and then each atomically waits until the counter reaches zero before continuing. It's used to synchronize (i.e. put into lockstep) two concurrent processes such that they must all wait at a given point before continuing more or less all at once, often as part of a larger process.
If you mean a barrier in terms of a memory "fence", that's an event on CPUs whereby any pending memory instructions that have been pipelined and thus not committed are forced to commit and complete before continuing. Usually only relevant for a single core, but they're used to make sure that other cores will see the same memory values and your pending writes would reflect (or, conversely, sometimes making sure your own core sees the reads from other cores as fresh as possible before the actual read op).
Paul McKenney's "Memory Barriers: a Hardware View for Software Hackers" is excellent, with Preshing's blog (preshing.com) offering more approachable explanations for beginners.
In a multi-threaded context, memory reads and writes can be reordered by hardware. It gets more complicated with shared cache. Imagine that you have core 1 writing to some address at (nearly) the same time that core 2 reads from that. Does core 2 read the old or the new? Especially if they don't share the same cache -- core 1 might "write" to a given address, but it only gets written to core 1's cache and then "scheduled" to be written out to main memory. Meanwhile, later core 2 tries to read that address, it's not in its cache, so it pulls from main memory before core 1's cache has flushed. As far as core 2 is concerned, the write happened after it read from the address even though physically the write finished in core 1 before core 2's read instruction might have even started.
A memory barrier tells the hardware to ensure that reads-before is also "happens-before" (or after) a given writen to the same address. It's often (but not always) a cache and memory synchronization across cores.
I found Fedora Pikus's cppcon 2017 presentation [1] to be informative, and Michael Wong's 2015 presentation [0] filled in some of the gaps.
C++, being a generic language for many hardware implementations, provides a lot more detailed concepts for memory ordering [2], which is important for hardwares that have more granularity in barrier types that what most people are used to with x86-derived memory models.
> I know from experience that well designed messages with secure code are very understandable
This premise seems flawed.
How can you possibly know from experience that something is “very understandable” if the only brain you have is your own?
How do you anticipate how other people with brains different from yours are going to behave in situations of cognitive impairment or extreme stress, things that happen in the real world?
I can assure you that by now, my brain is conditioned to lock into the four-digit code as soon as it can, entirely ignoring everything around it, including the words to the left.
I’m an avid reader. But there are limits to what I can process, and our world has become so full of noise that it has become a coping strategy for brains to selectively ignore stuff if they feel it’s not important at the moment. That effect becomes even more pronounced as the brain deteriorates with age.
I don't know if you're sarcastic or just missing the problem; which is that people will be presented with lika a facebook login page, on a site with url like `facebook.quick-login.com` or `facebock.com` and they'll enter the passcode since as fair as they were concerned, they did everything correct. The disclaimer does shit preventing that, they »obviously« didn't share the code with any other website, they entered it on the facebooks as they were told!
I am sarcastic because this discussion is about a different attack. Not about fishing.
(The OP says one time codes are worse than passwords. In case of fishing passwords fail the same way as one time codes.)
I was also sarcastic/provocative even in the prev comment, saying the GOOD site always includes a warning with the code making the attack impossible. A variation of the attack is very widely used by phone scammers: "Hello, we are updating intercomm on your appartment block. Please tell us your name and phone number. Ok, you will receive a code now, tell it to us". Yet many online services and banks still send one time codes without a warning to never share it!
The fishing point may also be used in defence of one time codes: if the GOOD service was using passwords instead of one time codes, the BAD could just initiated fishing attack, redirecting the user to a fake login page - people today are used to "Login with" flow.
Played 145 times
Max credits 49
Max combo 8
Win 56 (39%)
Draw 35 (24%)
Loss 54 (37%)
My "this game" stats:
Played 94 times
Current credits 45
Max credits 49
Max combo 8
Win 39 (41%)
Draw 25 (27%)
Loss 30 (32%)
I was playing mostly as with a living oponent.
When playing I was not exploiting any assumptions about it being Markov learner (I don't even understand how it learns and how to exploit it)
While it can not learn to beat me most of the time, it is playable.
How do you know it learns with markov chain? How exactly? (What states the chain has? Other details?)
Why does camera shakes at every move? To me that's very annoying.
The game needs stats of the total credits I spent including previous rounds, so that I see the total spent/won balance.
I am clearly winning on that measure.
> How do you know it learns with markov chain? How exactly? (What states the chain has? Other details?)
I wrote it! It uses five chains of different lengths, and each of those estimates the next, then a standard way of resolving those to a single signal.
> Why does camera shakes at every move? To me that's very annoying.
Yeah, it is. The first version you actually spun around on the spot too, which was cool but made you sick, even on a phone. Therefore I hacked it to this, but it's not great.
> The game needs stats of the total credits I spent including previous rounds, so that I see the total spent/won balance. I am clearly winning on that measure.
In the menu there is "statistics" which contains more stats than live stats, and that might have more of what you want!
I once was reading a software license, and deep inside it there was a promise: who has read till this place will get a certain prise. I emailed them, they kind of confirmed that I am eligible for the prise. But it was a far away city, so I never went to claim it.
LOL
reply