mutex .vs atomic operation
rich coco
the context of C/C++).
can one infer from that that it is unnecessary to have to mutext-protect
a char value
(eg, a flag) shared by multiple threads?
what about 'bool' types? are bool read/write operations guaranteed
'atomic' and therefore
not in need of mutex-protection?
Tia,
- rich
Arnold Hendriks
> I understand write/read access to a 'char' is "guaranteed atomic" (in
> the context of C/C++).
> can one infer from that that it is unnecessary to have to mutext-protect
> a char value
> (eg, a flag) shared by multiple threads?
No, since the assumption you are inferring from is invalid in the generic
case. It may only apply on a specific platform - you didn't tell which.
> what about 'bool' types? are bool read/write operations guaranteed
> 'atomic' and therefore
> not in need of mutex-protection?
For standard POSIX, every access to memory shared by threads requires
locking. And even unshared memory may require locking if it is too close
to shared memory (word tearing).
--
Arnold Hendriks <a.hen...@b-lex.com>
B-Lex Information Technologies, http://www.b-lex.com/
Pete Becker
>
> I understand write/read access to a 'char' is "guaranteed atomic" (in
> the context of C/C++).
There's no such requirement.
>
> can one infer from that that it is unnecessary to have to mutext-protect
> a char value
> (eg, a flag) shared by multiple threads?
Even if your initial assumption is correct (as it often is), this
doesn't follow from it. Consider a system wtih two CPUs, and each CPU
has its own memory cache. Writing to one CPU's cache doesn't affect the
corresponding value in the other CPU's cache.
>
> what about 'bool' types? are bool read/write operations guaranteed
> 'atomic' and therefore
> not in need of mutex-protection?
>
Mutex locks and unlocks have an important side effect: they synchronize
data in CPU caches.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
David Schwartz
>
> I understand write/read access to a 'char' is "guaranteed atomic" (in
> the context of C/C++).
atomic != thread safe
> can one infer from that that it is unnecessary to have to mutext-protect
> a char value
> (eg, a flag) shared by multiple threads?
Nope. An atomic access is uninterruptible with respect to a single
processor but may or may not lock the bus. Consider:
int i;
i=i+1;
Even if the 'i=i+1' is atomic, it can be implemented by disabling
interrupts, fetching 'i', adding one to it, then writing it back, then
re-enabling interrupts. This is atomic -- it cannot be interrupted by a
signal or stopped to begin some other operation on this processor.
However, two processors running this code at exactly the same time can
result in only '1' being added.
Please, follow the memory visibility rules of whatever threading model
you are using.
DS
Anshuman Kanetkar
> I understand write/read access to a 'char' is "guaranteed atomic" (in
> the context of C/C++).
>
> can one infer from that that it is unnecessary to have to mutext-protect
> a char value
> (eg, a flag) shared by multiple threads?
>
I think you are confusing granularity of your Microprocessor's
primitive operations (read and write) with the granularity of your
transactions on the variables in your program. Remember that locking
is used to guarantee atomicity of a *transaction* . If your
transaction encompasses multiple reads and writes (for instance, a
'test and
set' kind of operation), it is no longer atomic, (even though it is
composed of multiple atomic operations) and will break down with
mutithreaded code unless you provide some kind of explicit mutual
exclusion mechanism.
This is very critical information - your multithreaded code will break
if you do not realise
which part of your code is non-reentrant.
> what about 'bool' types? are bool read/write operations guaranteed
> 'atomic' and therefore
> not in need of mutex-protection?
>
Again, this depends on the operation you are performing, and whether
you test the
value of your Bool flag within a 'critical section' (non-reentrant
portion) in your code. This applies to 'char' values as well.
for instance if you have a pair of producer consumer threads:
bool isEmpty;
int data
/* Producer thread */
void
produce()
{
while (1)
{
while (!isEmpty);
addToQueue(); /* write something to data */
isEmpty = false;
}
}
/* Consumer Thread */
void
consume()
{
while (1)
{
while(isEmpty);
deleteFromQeue(); /* read something from data */
isEmpty = true;
}
}
In the above code sequence, testing the flag and and setting its new
value
needs to be an atomic operation, and you cannot use
read/writes to guarante atomicity of this transaction. So to correct
the race condition there, you have to protect it with a mutex, or use
an atomic test and set operation like so:
while (1)
{
while (atomic_test(isEmpty, value)); /* lock */
doWhatever();
atomic_set(isEmpty, ! value); /* unlock */
/* Under C/C++ on IA32, Usually Equivalent to isEmpty = ! value; */
}
Hope this answers your question...
rgds,
Anshuman
> Tia,
>
> - rich
rgds,
Anshuman.
------------------------------------------
Anshuman Kanetkar
http://www..calsoftinc.com/
Edward A Falk
Arnold Hendriks <a.hen...@b-lex.com> wrote:
>rich coco <rac...@sockeye.com> wrote:
>> I understand write/read access to a 'char' is "guaranteed atomic" (in
>> the context of C/C++).
>How did you come to that understanding? No such guarantee is made.
In fact, I can easily believe that it's not true. A 32-bit machine
that doesn't have byte access would have to use read-modify-write
to access a char. PDP-10 might fall into that category.
--
-ed falk, fa...@falconer.vip.best.com. See *********************#*************#*
http://www.rahul.net/falk/whatToDo.html #**************F******!******!*!!****
and read 12 Simple Things You Can Do ******!***************************#**
to Save the Internet **#******#*********!**WW*W**WW*****