Threads + Context Switching

[Nositi]

Hi,
I'm looking for race conditions in a small piece of code, and there is one particular thing I'm looking at.

If I have a line like this:

list[n++] = item;

this translates to

list[n] = item;
n++;

So I am I right in thinking that this assignment to list[n] could occur, then a bunch of code from another code is executed before n++?

Thanks.

[matsp]

Well, you would actually have to look at the assembler code generated by the compiler to determine that - it would depend on the actual processor being used exactly what instructions you get and whether there is a mouse-hole or one that you can drive a bus through.

But indeed, there is no guarantee that n++ is executed as part of the actual line above. Nor that the compiler generates instructions that in themselves don't violate some threading rules. C is not, in and of itself, a threadsafe language. You have to MAKE such things sure in your design of the software.

--
Mats

[Nositi]

Ok, make sense. I suppose there is no harm in assuming that it will be executed separately.

Thanks.

[Codeplug]

>> I'm looking for race conditions...
If you don't see any thread synchronization 'primitives' like pthread_mutex_lock() or EnterCriticalSection() proctecting shared memory access, then it's safe to assume that there are race conditions - until proven otherwise.

gg

[Nositi]

Oh I know there are race conditions, I have to find them. This is for an assignment, I just wasn't sure about that one.

[Elysia]

OK, here's the general rule:
If any threads access a shared resource, such as the same variable, you must use thread synchronization, such as critical sections.
If you need a thread to do something before any other, then events might do the trick.
If one thread mustn't be disturbed while doing some important work that is also important to the other thread, use critical sections or the like.

Good luck.

[matsp]

Most OS's also have constructs such as "LockedIncrement()", "LockedDecrement()", "CompareAndSwapLocked()" which is guaranteed to be thread/context safe (although the latter may do "nothing" and return a result to indicate that "nothing was done", depending on the circumstances in which it is used).

Note that even a simple statement such as "n++" is not guaranteed to be one instruction on all platforms - for example RISC processors would do this as a "read, modify, write". On processors that support complex instructions, the compiler may well BE ABLE to use this construct, but choose not to do so because n is used in such a way that the compiler thinks it's better to use a register, e.g. the above "list[n++] = item" can become:

    mov  eax, n
    mov  edx, list
    mov  [edx+eax*4],item
    inc  eax
    mov n, eax

This is "simplified syntax x86 assembler, so may not be 'compiler friendly'... ".

--
Mats