Re^2: using parallel processing to concatenate a string, where order of concatenation doesn't matter

Replies are listed 'Best First'.
Re^3: using parallel processing to concatenate a string, where order of concatenation doesn't matter by BrowserUk (Patriarch) on Oct 18, 2006 at 19:03 UTC
On my single cpu processor, only one thread runs at a time, so there is no race condition. On a multi-cpu machine, reading the docs on, and using threads::shared::`lock()` will be required. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply] [d/l] [select]
Re^4: using parallel processing to concatenate a string, where order of concatenation doesn't matter by ikegami (Patriarch) on Oct 18, 2006 at 19:32 UTC
Race conditions can occur even if only one thread is running a time. What matters is when one thread can interrupt another thread. Consider two threads doing `i+=1` in C. `i+=1 CPU ----------+---------- thread 1 \| thread 2 ==========+========== ... \| T load i \| i add 1 \| m ----------+---------- e \| ... \| \| load i \| \| add 1 v \| save i \| ... ----------+---------- save i \| ... \|` [download] Even though both threads have run, and even though only one thread executed at a time, `i` was only incremented by one. So my question remains. Is `.=` atomic (i.e. uninterruptable, safe) or does it introduce a race condition (like C's `i+=1`, requiring the use of locks)? Update: Answered in Threads: why locking is required when using shared variables.	[reply] [d/l] [select]