CODEWITHSUNDEEP
cmultithreading
user13117115
user13117115

Reputation:

Is Atomicity still a concern if threads are not used?

As far as I know, atomicity (which could be accomplished using locks, which uses memory barriers) are put in place so an operation is either fully done, or not started from the point of view of different threads.

My question is, if we have a single threaded program, is atomicity still a concern?

Upvotes: 1

Views: 99

Answers (3)

chqrlie
chqrlie

Reputation: 144969

Atomicity is a concern if the program accesses data that may change asynchronously. Shared data structures are an obvious case of such data, but other examples can be found in single threaded processes:

  • memory shared with other processes via mmap
  • memory accessed by asynchronous signal handlers
  • memory mapped hardware registers
  • memory updated asynchronously by device drivers

Such data must be declared volatile and atomic access is highly preferable to avoid undefined behavior.

If your single threaded process does not have such data, atomic access is not a concern.

Upvotes: 3

0___________
0___________

Reputation: 67820

If there is nothing which can change the object outside the normal program execution flow (ie no side effects) the atomicity is not the issue.

Upvotes: 0

David Schwartz
David Schwartz

Reputation: 182829

Sure, but only in fairly limited situations that essentially involve interacting with another thread that is not part of the single-threaded program or processing outside the CPU such as on a GPU or coprocessor.

For example, consider two instances of a single-threaded program interacting with each other through shared memory. Consider an application interacting with data structures maintained by kernel code that runs in its own thread. Consider an application interacting with data structures in RAM that are also mapped to other hardware such as a video card or transputer.

One other case might be code that could be interrupted by a signal.

Upvotes: 5

Related Questions