How computers work

[iamtheky]

I dont think a single thread can have a 'race condition'.  Clients certainly can.  NAN errors should never happen either, but people write shitty code that doesnt account for other peoples shitty code, and they both make requests of another persons shitty code that is making requests of shared resources based off their poorly validated input.

Edited March 6, 2016 by iamtheky

[trancexx]

47 minutes ago, iamtheky said:

I dont think a single thread can have a 'race condition'.  Clients certainly can.  NAN errors should never happen either, but people write shitty code that doesnt account for other peoples shitty code, and they both make requests of another persons shitty code that is making requests of shared resources based off their poorly validated input.

Race condition can happen with single threaded design too. For example some APIs require code to be reentrant. For example, "reentrant function" means that function can safely be called at any point, even if not previously ended. Keyword is "interrupt".

@JohnOne, what difference would it make if it's one cycle? That's irrelevant. It depends on ten different things for it to matter.

[JohnOne]

Because despite all the info, I still don't get it, so I'm trying to get specific things cleared up that I'm hung up on.

[RTFC]

In machine code, an INC(rement) opcode (or an ADD, for that matter) acting on a register (assuming your int is already loaded into that register) or memory location is itself atomic, taking one clock cycle (or tick) on an ALU (which is part of your CPU), and depending on your architecture, multiple INCs (3 is common) can even be handled within a single clock tick, although other bottlenecks in the pipeline may limit this again).  See these tables to get an idea of the basic latencies of various instructions.

But in your high-level world of compiled or interpreted instructions, you're doing much more than that: you allocate some memory for your integer variable first, then you fill it with an initial value, you add unity to that memory location using an ADD or INC instruction, either directly or indirectly (if you had stored that value of one somewhere else before, and have to load it first), and then you may wish to evaluate the result and decide to do something depending on the outcome, as in trancexx's example. All of those steps cost clock ticks; some are handled by ALUs, others by AGUs, floating point maths is handled by your FPU, etc. Many instructions require multiple CPU units to interact, and some single opcodes require over one hundred clock ticks to complete. Special scheduling units attempt to keep the pipelines optimally filled, but cache misses, faults, exceptions, and even suboptimal memory alignment of addresses and buffer sizes all degrade performance. Now imagine this in an environment where dozens or hundreds of threads are vying for processing time and memory, and the CPU is always simultaneously playing catch-up and divide-and-conquer.

So you're missing the point if you're thinking purely in terms of your single INC in a single thread. Your CPU itselfs consists of numerous parts working on numerous jobs, and constantly switching to keep as many tasks going in parallel as possible, as efficiently as possible. This means that any thread can be temporarily suspended at any point (and not necessarily always when a full instruction is completed, if that instruction takes more than one clock tick), so if any information is shared between threads, or acted upon and evaluated by multiple threads, race conditions may occur, unless the programmer explicitly adds safeguards to prevent this.

Edited March 9, 2016 by RTFC
clarification

[toasterking]

On 3/2/2016 at 1:57 AM, JohnOne said:

On 3/2/2016 at 1:57 AM, JohnOne said:

a CPU only carries out one instruction at a time, meaning linear, and that is regardless of how many cores it might have.

[...]

So if it is true, why ever does a race condition between processes or threads occur?

Because the two actually have little to do with each other.  A race condition doesn't occur when the CPU does more than one thing at a time; a race condition occurs when two separate code paths (each representing many, many individual CPU instructions) have each been partially executed and the next one to have a turn is not aware of what the other one has been working on and makes an assumption.

Imagine you're a customer (line of code) in a store (execution environment).  There are two lines (threads) of customers all waiting to check out, but only a single cashier (CPU) who services each line of customers arbitrarily (preemptive multitasking).  The cashier (CPU) is processing all the transactions (instructions) that keep the store (OS) running, but you don't necessarily care how the cashier does their job because you're just a shopper (a programmer of code in a high-level language) and that's not your job.  You're waiting to buy a box of allergy medication (obtain a handle to a resource) which is stocked behind the counter.  When you get in line, you count the number of people in front of you and calculate that there are enough boxes of the medication on the shelf for you to get one even if every person in front of you does.  Just before you get to the register, someone buys the last box.  What happened?  Oh sh*t, you weren't paying attention to the other line.  The cashier is oblivious to your massive fail and continues processing transactions like normal.  You exit the store anyway (you did no error checking) and are stungbitten by a vampire bee.  Without your medication (resource) you have an allergic reaction and die.  You've crashed due to a race condition!

Okay, so my analogy could probably use a little work, but hopefully you get the idea.

When I was learning this stuff, a video of a talk that Allen Downey gave on his book The Little Book of Semaphores and the demonstrations he gave made a lot of sense to me.  Unfortunately, it appears that the video has been removed from YouTube.  But look, I can still prove that it once existed!  http://web.archive.org/web/20150511150444/https://www.youtube.com/watch?v=RaEUw107dpg

[JohnOne]

So what's happened is, what I thought was a race condition, is wrong.

I thought a race condition was supposed to be 2 threads trying to change mrmory at the exact same time an hence on thread failing.

Meh, I've been even dumber than this believe it or not.

Thank you everyone for your help, I appreciate your time and patience.

[RTFC]

13 minutes ago, JohnOne said:

Meh, I've been even dumber than this believe it or not.

Hey, don't put yourself down like that, JohnOne.

It's a good question; it's just that a CPU is an incredibly sophisticated and complicated piece of kit (other chips on the motherboard are much simpler beasts, with the possible exception of the GPU), so the moment you leave the highest abstraction layer, you slide down the rabbit hole and have to deal with odd analogies to get a handle on what's going on (funnily enough, when you dig even deeper to the core hardware, things appear to get simpler, but then quantum effects start to kick in and then you're truly lost). But if everyone were satisfied just clicking buttons and sharing cat videos, we'd never get anywhere interesting and new.

 

[JohnOne]

Cheers, I know but it's just my way of acknowledging my own mistake. I should have realized after my web searches turned up nothing, that I was asking the wrong question. I never stopped to question my assumption of what a race condition was.

I was way ahead of myself, visualizing two electrons representing two linear operations of a CPU racing toward a destination taking two different paths, and even considering Heisenberg's uncertainty principle.

Now come on, you have to lol at that, a little.

[RTFC]

Do I detect subliminal remnants of those silly TRON motorcycles zipping around your brain?

[jvanegmond]

On 3/7/2016 at 11:30 AM, RTFC said:

 

Maybe nitpicking but, INC is not atomic in x86 and you missed bad branch predictions as a leading cause of performance woes, which is arguably the most important next to caching behavior.

 

@JohnOne you may enjoy http://www.nand2tetris.org/ . I can highly recommend it. Skip the stuff you already know and get programming. You can even do it in AutoIt if you are uncomfortable doing the instructions as suggested.

[JohnOne]

4 hours ago, RTFC said:

Do I detect subliminal remnants of those silly TRON motorcycles zipping around your brain?

haha, something like that.

 

2 hours ago, jvanegmond said:

@JohnOne you may enjoy http://www.nand2tetris.org/ . I can highly recommend it. Skip the stuff you already know and get programming. You can even do it in AutoIt if you are uncomfortable doing the instructions as suggested.

looks good for when I have time, thanks.

[toasterking]

I think it is also worth mentioning that race conditions can occur even within a single thread as long as there is some scheduling mechanism for the code execution (à la coprocesses) and resources are shared.  Race conditions are possible in an AutoIt script if, for example, code in the main loop and code in a function called by AdLibRegister() manipulate the same shared data.  I started a thread a few years ago in which I went apeshit on that concept: