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

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.

Comment on Re^3: using parallel processing to concatenate a string, where order of concatenation doesn't matter Select or Download Code

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]