OSDev.org

• If you're reading from a dereferenced pointer more than once in the same function, where that pointer points to data that may be modified by another thread/interrupt handler/signal handler/etc.
• If you're reading from a global variable more than once in the same function that might be modified by another thread/interrupt handler/signal handler/etc.
• If you're reading from a local variable more than once in the same function and some other thread/interrupt handler/signal handler/etc. has a pointer to that local variable through which they can modify it (yucky, but possible).

Colonel Kernel wrote:Multiple threads can access the status of a GimmeStatus simultaneously and get the same answer, and if one of the threads sets the status, the other threads will at some point see the new status, and not some messed up half-and-half (which might happen if the reads and writes were to unaligned memory).

Colonel Kernel wrote:What happens if the compiler inlines the call to getStatus() and the optimizer puts the status field in a register? Could this happen?

gaf wrote:Volatile won't help you here as it only says that a memory word may not be cached but has to be read/written every single time it is accessed from memory.

Incidentally, this issue is not related to CPU caches except that re-loading of variables into registers may involve cache hits or misses.

To me your problem looks like a classical race situation which might be solved using a mutex/semaphore..

Colonel Kernel wrote: I realize that if I implemented an "atomic_read()" function it would make this problem go away -- not because the read would be atomic (which it probably already is), but because it would be an asm function that the compiler can't inline and the optimizer can't touch. It's just that this seems to me to be the purpose of volatile in the first place...

JoeKayzA wrote:Had a quick look at your code. 'volatile' would do exactly what you need, IMO, so why not use it?

Inside a critical section defined by a mutex, only one thread has access. Consequently, inside a critical section, the executing code has single-threaded semantics. The controlled variable is not volatile anymore ? you can remove the volatile qualifier.

void thread1()
{
    // Wait for the status to change.
    LockMutex( globalStatus.mutex );
    register int cachedStatus = globalStatus.status;
    if (cachedStatus != 0) goto end_loop;
    UnlockMutex( globalStatus.mutex );
    do_something_else();

start_loop_pass_2:    
    LockMutex( globalStatus.mutex );
    if (cachedStatus != 0) goto end_loop;
    UnlockMutex( globalStatus.mutex );
    do_something_else();
    goto start_loop_pass_2;

end_loop:
    do_something_important();
}

Colonel Kernel wrote:I discovered this article which is quite interesting. However, there is something there that I can't quite bring myself to believe:

"Inside a critical section defined by a mutex, only one thread has access. Consequently, inside a critical section, the executing code has single-threaded semantics. The controlled variable is not volatile anymore - you can remove the volatile qualifier."

AR wrote:Your globalStatus example would probably fit this whereas if you mutexed the whole function rather than individual accesses then you could avoid volatile [since the variable is locked for the scope of the function, it can be guaranteed that the only modifications will come from the current path of execution].

Code: Select all

int globalvar;
int multithreadproblem()
{
    //Although it applies to the pointer rather than the source, it should make no difference as it will continually reread the source in case the pointer changed
    volatile int *globalvarptr = &globalvar;

    ...
}

(Note that this is derived mainly from logical deductions based on various bits of documentation without direct testing)

int* volatile foo;

gaf wrote:The 'remove' doesn't mean that you the class needn't be declared as volatile any longer but just that, while inside the mutex, the data can be accessed as in a single threaded app and caching is thus possible. Once the critical region is left, however, the data is volatile again as it can be modified by another thread.

    int getStatus() const volatile
    {
        int myStatus = 0;
        LockMutex( this->mutex );
        GimmeStatus* nonVolatileThis =
            const_cast<const GimmeStatus*>( this );
        myStatus = nonVolatileThis->GetStatus();
        UnlockMutex( this->mutex );
        return myStatus;
    }

    // Single-threaded version.
    int getStatus() const
    {
        return this->status;
    }