POSIX Streams and Global Variables in C on Linux
If I have two threads and one global variable (one thread constantly loops to read the variable, and the other constantly loops to write to it), something happens that shouldn't? (ex: exceptions, errors). If so, what is the way to prevent it. I read about mutex locks and that they allow exclusive access to a variable by one thread. Does this mean that only this thread can read and write to it and the other?
source to share
Does anything happen that shouldn't?
It depends partly on the type of variables. If the variable is, say, a string (a long array of characters), then if the writer and the reader access it at the same time, it is completely undefined, as the reader will see.
This is why mutexes and other coordination mechanisms are provided by pthreads.
Does this mean that only this thread can read and write to it and the other?
The mutex ensures that no more than one thread using the mutex can have permission to continue. All other threads using the same mutex will be held until the first thread releases the mutex. Therefore, if the code is written correctly, only one thread will be able to access the variable at any time. If the code is not written correctly, then:
- one thread can access a variable without checking that it has permission to do so.
- one thread can receive a mutex and never release it
- one thread can destroy the mutex without notifying the other
None of these are desirable behaviors, but the mere existence of the mutex does not prevent any of these cases.
However, your code can intelligently use mutexes and then access to the global variable will be appropriately controlled. Although it has permission through a mutex, either the thread can modify the variable or just read the variable. Any of them will be safe from interference with the other thread.
source to share
Does this mean that only this thread can read and write to it and the other?
This means that only one thread can read or write a global variable at a time.
These two threads will not race among them to access a global variable, nor will they access it simultaneously at any given point in time.
In short, access to the global variable is Synchronized .
source to share
The first; In C / C ++, the unsynchronized read / write function of a variable does not throw any exceptions or system errors, BUT it can generate application-level errors - mainly because you can hardly fully understand how memory is accessed, and is it atomic if you don't look at the generated assembler. A multi-core processor can probably create harsh debugging conditions when accessing shared memory without synchronization.
Hence,
Secondly; You should always use synchronization - like mutex locking - when dealing with shared memory. Locking a mutex is cheap; so it won't really have a performance impact if done correctly. Rule of thumb; keep lcok as short as possible, e.g. just to read / increase / write shared memory.
However, from your description, it looks like one of your threads is not doing anything, but waiting for the common mode to change state before doing anything is bad multithreading design that requires unnecessary processor restart, so
Thirdly; Have a look at using semaphores (sem_create / wait / post) to synchronize between your threads if you are trying to send a "message" from one thread to another
source to share
As others have said, when communicating between threads through "normal" objects, you need to watch out for race conditions. In addition to mutexes and other blocking structures that are relatively heavy, the new C (C11) standard provides atomic types and operations that ensure race-free behavior. Most modern processors provide instructions for these types, and many modern compilers (in particular gcc on linux) already provide their respective interfaces for such operations.
source to share