Let's break this definition down into simpler terms. One of the best metaphors to describe a race condition is if we imagine writing a banking application that updates your account balance whenever you deposit or withdraw any money from that account.
Imagine, we started with £2,000 in our bank account, and say we are about to receive a bonus of £5,000, because we managed to bug fix a concurrency issue in work that was costing the business millions. Now also imagine that you are also to pay a rent of £1,000 on the same day--this is where a potential race condition could leave you out of pocket.
If our banking application had two processes, one of which dealt with the withdrawing, Process A, and the other which dealt with the depositing, Process B. Say Process B, which deals with deposits into your account, reads your bank balance as £2,000. If Process A was to start its withdrawal for the rent just after Process B starts its transaction, it would see the starting balance as £2,000. Process B would then complete its transaction, and correctly add £5,000 to our starting £2,000, and we'd be left with the grand sum of £7,000.
However, since Process A started its transaction thinking that the starting account balance was £2,000, it would unwittingly leave us bonus-less when it updates our final bank balance to £1,000. This is a prime example of a race condition within our software, and it's a very real danger always waiting to strike us in the most unfortunate ways.