Why is this unsafe for multithreading?

I am trying to understand if/why sharing a simple 'int' variable is unsafe = in a multithreading context, under the assumption that only one thread writ= es on it, and the other threads only read it. I understand that without further constrains the fact that other threads on= ly read the int is a matter of blind confidence in the programmer. I also u= nderstand that there are atomic templates or interlocked operations that ar= e widespread and easy to use. But nonetheless I would like to know if there= is something more fundamental about the unsafety of a shared 'int' that I = quite don't get in this particular situation where only one thread is expec= ted to modify the data.

On 08.07.2012 21:09, user8583@gmail.com wrote: > I am trying to understand if/why sharing a simple 'int' variable is unsafe in a multithreading context, under the assumption that only one thread writes on it, and the other threads only read it. > > I understand that without further constrains the fact that other threads only read the int is a matter of blind confidence in the programmer. I also understand that there are atomic templates or interlocked operations that are widespread and easy to use. But nonetheless I would like to know if there is something more fundamental about the unsafety of a shared 'int' that I quite don't get in this particular situation where only one thread is expected to modify the data. > Don't post with Quoted Printable.

user8583@gmail.com wrote 2012-07-08 21:09: > I am trying to understand if/why sharing a simple 'int' variable is unsafe in a multithreading context, under the assumption that only one thread writes on it, and the other threads only read it. > > I understand that without further constrains the fact that other threads only read the int is a matter of blind confidence in the programmer. I also understand that there are atomic templates or interlocked operations that are widespread and easy to use. But nonetheless I would like to know if there is something more fundamental about the unsafety of a shared 'int' that I quite don't get in this particular situation where only one thread is expected to modify the data. > Depending on your hardware, the other threads (cores) might not see the updates, or not see the same value at the same time. Bo Persson

Hello user and Bo! On Sunday, July 8, 2012 5:46:09 PM UTC-4, Bo Persson wrote: > user...@...com wrote 2012-07-08 21:09: > > I am trying to understand if/why sharing a simple 'int' variable is uns= afe in a multithreading context, under the assumption that only one thread = writes on it, and the other threads only read it. > > > > I understand that without further constrains the fact that other thread= s only read the int is a matter of blind confidence in the programmer. I al= so understand that there are atomic templates or interlocked operations tha= t are widespread and easy to use. But nonetheless I would like to know if t= here is something more fundamental about the unsafety of a shared 'int' tha= t I quite don't get in this particular situation where only one thread is e= xpected to modify the data. > > >=20 > Depending on your hardware, the other threads (cores) might not see the= =20 > updates, or not see the same value at the same time. >=20 > Bo Persson Furthermore, the reader threads may even see an inconsistent or garbage value. Admittedly, this is more likely with a long or a double than an int, but the language offers no guarantee. Consider a four-byte int and hardware where bytes are written one at a time. The writer thread might have written only one of the four bytes when a reader thread reads the int. The reader thread then gets one new byte and three old bytes, neither the old value of the int nor the new. I haven't seen this with ints, but I have seen it with doubles. I had the misfortune one time of using an explicitly multi- threaded third-part library that had a thread use unprotected (neither atomic nor mutex-protected) writes to update some doubles. Client code would then read those doubles. Every once in a while you would get garbage (neither the old nor the new value of the double), because only one four-byte word of the eight-byte double had been written when the read occurred. Note, without synchronization on the library side, there was nothing that the client code could do to prevent this problem (other than try to guess whether the value was bogus, and re-read the double until it became "good"). Good luck. K. Frank

On Jul 8, 12:09 pm, user8...@gmail.com wrote: > I am trying to understand if/why sharing a simple 'int' variable is unsafe > in a multithreading context, under the assumption that only one thread > writes on it, and the other threads only read it. > > I understand that without further constrains the fact that other threads > only read the int is a matter of blind confidence in the programmer. I also > understand that there are atomic templates or interlocked operations that > are widespread and easy to use. But nonetheless I would like to know if > there is something more fundamental about the unsafety of a shared 'int' > that I quite don't get in this particular situation where only one thread > is expected to modify the data. For real world uses AFAIK, here are potential problems. 1- Tearing. int might not be atomically updated, and thus you might get "values out of thin air". 2- Lack of immediate updates. A wonderful example is: int x; //... while (x) do_something(); If the compiler can prove that do_something() does not write to b (such as by inline expansion), then the compiler can transformation that to: int x; //... int tmp = x; while (tmp) do_something(); Rendering you dead in the water. There's an obscure rule in the C++11 standard that prevents this kind of transformation, but only for atomic reads, not regular reads. 3- Everything I don't know about.

On Sun, 08 Jul 2012 12:09:34 -0700, user8583 wrote: > I am trying to understand if/why sharing a simple 'int' variable is unsafe > in a multithreading context, under the assumption that only one thread > writes on it, and the other threads only read it. Reading and writing an "int" are not *guaranteed* to be atomic operations. On systems where the data bus is narrower than an int, it may require multiple transfers, meaning that the reader may see a partially-modified value. On systems where the data bus is wider than an int, writing a single int may require a read-modify-write cycle. If another CPU concurrently writes to another int which is packed into the same word, one of the writes may be lost. The former is unlikely on typical systems (i.e. where an int is no larger than a word, and is aligned to a word boundary). The latter was specifically addressed in C++11, IIRC.

Nobody <nobody@nowhere.com> writes: >On Sun, 08 Jul 2012 12:09:34 -0700, user8583 wrote: > >> I am trying to understand if/why sharing a simple 'int' variable is unsafe >> in a multithreading context, under the assumption that only one thread >> writes on it, and the other threads only read it. > >Reading and writing an "int" are not *guaranteed* to be atomic operations. > >On systems where the data bus is narrower than an int, it may require >multiple transfers, meaning that the reader may see a partially-modified >value. Ok. Name a single system still in use where the data bus is narrower than an int. scott

On 09 Jul 2012 15:04:53 GMT, scott@slp53.sl.home (Scott Lurndal) wrote: >Nobody <nobody@nowhere.com> writes: >>On Sun, 08 Jul 2012 12:09:34 -0700, user8583 wrote: >> >>> I am trying to understand if/why sharing a simple 'int' variable is unsafe >>> in a multithreading context, under the assumption that only one thread >>> writes on it, and the other threads only read it. >> >>Reading and writing an "int" are not *guaranteed* to be atomic operations. >> >>On systems where the data bus is narrower than an int, it may require >>multiple transfers, meaning that the reader may see a partially-modified >>value. > >Ok. Name a single system still in use where the data bus is narrower than an int. AVRs are 8-bit CPUs. Ints are normally 16 bits on AVR C implementations. There are others, but you only asked for one... ;-)

Robert Wessel <robertwessel2@yahoo.com> writes: >On 09 Jul 2012 15:04:53 GMT, scott@slp53.sl.home (Scott Lurndal) >wrote: > >>Nobody <nobody@nowhere.com> writes: >>>On Sun, 08 Jul 2012 12:09:34 -0700, user8583 wrote: >>> >>>> I am trying to understand if/why sharing a simple 'int' variable is unsafe >>>> in a multithreading context, under the assumption that only one thread >>>> writes on it, and the other threads only read it. >>> >>>Reading and writing an "int" are not *guaranteed* to be atomic operations. >>> >>>On systems where the data bus is narrower than an int, it may require >>>multiple transfers, meaning that the reader may see a partially-modified >>>value. >> >>Ok. Name a single system still in use where the data bus is narrower than an int. > > >AVRs are 8-bit CPUs. Ints are normally 16 bits on AVR C >implementations. There are others, but you only asked for one... ;-) Actually, modern AVR's are 32-bit. Yet, I should have said name a single multicore processor with a data bus narrower than an int given the orignal posting.

On 09 Jul 2012 16:53:26 GMT, scott@slp53.sl.home (Scott Lurndal) wrote: >Robert Wessel <robertwessel2@yahoo.com> writes: >>On 09 Jul 2012 15:04:53 GMT, scott@slp53.sl.home (Scott Lurndal) >>wrote: >> >>>Nobody <nobody@nowhere.com> writes: >>>>On Sun, 08 Jul 2012 12:09:34 -0700, user8583 wrote: >>>> >>>>> I am trying to understand if/why sharing a simple 'int' variable is unsafe >>>>> in a multithreading context, under the assumption that only one thread >>>>> writes on it, and the other threads only read it. >>>> >>>>Reading and writing an "int" are not *guaranteed* to be atomic operations. >>>> >>>>On systems where the data bus is narrower than an int, it may require >>>>multiple transfers, meaning that the reader may see a partially-modified >>>>value. >>> >>>Ok. Name a single system still in use where the data bus is narrower than an int. >> >> >>AVRs are 8-bit CPUs. Ints are normally 16 bits on AVR C >>implementations. There are others, but you only asked for one... ;-) > >Actually, modern AVR's are 32-bit. While AVR32s certainly exist (and are basically unrelated to the 8-bitters in terms of ISA), the traditional 8-bitters outsell the AVR32 by a huge margin. The AVR32s address a quite different market than the traditional AVRs.

On 7/9/2012 10:04 AM, Scott Lurndal wrote: > Nobody <nobody@nowhere.com> writes: >> On Sun, 08 Jul 2012 12:09:34 -0700, user8583 wrote: >> >>> I am trying to understand if/why sharing a simple 'int' variable is unsafe >>> in a multithreading context, under the assumption that only one thread >>> writes on it, and the other threads only read it. >> >> Reading and writing an "int" are not *guaranteed* to be atomic operations. >> >> On systems where the data bus is narrower than an int, it may require >> multiple transfers, meaning that the reader may see a partially-modified >> value. > > Ok. Name a single system still in use where the data bus is narrower than an int. > besides maybe some still lingering 8088 and 386SX systems?... actually, for the most part, one can be lazy and just mark the variables as 'volatile' and for the most part everything seems to work ok (at least on x86 and x86-64 systems). > scott >

On Mon, 09 Jul 2012 16:53:26 +0000, Scott Lurndal wrote: > Actually, modern AVR's are 32-bit. "AVR32" is 32-bit, but Atmel still sell plenty of 8-bit AVRs. Microchip sell 8, 16 and 32-bit PICs, 8051s and Z80s are still common. > Yet, I should have said name a single multicore processor with a data bus > narrower than an int given the orignal posting. Single core or multi-core makes no difference. Simple time-slicing on a single core is vulnerable to the same issue.