When to use Critical Sections in Threads?

[Aidman]

Hi, all

When is it necessary to use critical sections in a multithread application? I have read that it should be used when “manipulating shared resources”, but what do those that really mean? Does it mean when manipulating: global variables, allocated memory chunks or files? And does “manipulating” mean: reading (probably not), writing or reallocating? Could anyone please demonstrate some code examples for typical situations when critical sections should be used?

Thanks in Advance

[_Elixia_]

It's necessary to use critical sections when the running thread accesses an object that is also used by another thread. Eg. global variables, shared files, window handling code, and so on. It applies to both read, write and execute, as one thread can writing to a structure whilst another is reading and thus get garbage results.

On a multi-processor system, it may even be possible to read a dword value which has only been partially written by another processor (don't know if this can actually happen, but with multiple processors using the same memory space, anythings possible!)

[Cat]

As a typical rule, anytime you are working with any variable or object that is accessible to multiple threads, you should be doing it in a critical section, or otherwise synchronizing access. There are some types of situations that can happen simultaneously without trouble (two reads, for example), but a read at the same time as a write could cause major problems, so reads still need to pay attention to whether or not it's permitted to read.

As a corrolary, don't make an object visible to more threads than need to see the object. If a thread doesn't need to touch something, make sure it can't; you're vastly less likely to create bugs if you do this.

[Aidman]

Thanks mates

I think I am getting the idea. But a probebly need code some multithreading before I understand it more.

[adrianxw]

>>>
On a multi-processor system, it may even be possible to read a dword value which has only been partially written by another processor (don't know if this can actually happen, but with multiple processors using the same memory space, anythings possible!)
<<<

Modern processors manipulate values in their own cache, the "shared" memory is updated when the cache is flushed, and there are protection mechanisms for that operation, (although early systems did suffer from word tearing - this is unusual now).

What does happen in a multiprocessor system, (if you are not careful), is that more than one processor can load a variable into it's cache, then they modify it, CPU 1 flushes it's cache, storing the new value, then CPU 2 flushes, and overwrites the value previously stored by CPU 1.

Within task multithreading on a multiprocessor system requires the use of special techniques and/or a proper vectorising compiler.

[_Elixia_]

I didn't know that, thanks for pointing it out adrianxw.

[Cat]

Also, on most if not all modern machines, all writes of aligned dwords take place atomically; 32 bits of data are written at once.

[Aidman]

Thanks adrianxw

It seems like multithreading is worse than I thougth

[_Elixia_]

Note that if you do any windows I/O on the same file handle within a thread and the main program, you should use overlapped I/O to ensure they don't conflict with each other. Microsoft strongly discourage use of normal (ie. blocking) I/O in threads.

Now, normal C/C++ calls are non-overlapped functions, so these really shouldn't be used in threads in a Windows environment.

Just to add another trick... Overlapped I/O normally returns immediately whilst the I/O is in progress and it's up to the caller to check the completion status. Although you can ask windows to block if you get the IO PENDING status, they suggest it's not used in the main program because of upsetting the main message loop.

I get around this by getting the thread to send messages to the main program when IO is complete/etc.