I am a newbie to operating systems and every answer I&#39;ve found on Stackoverflow is so complicated that I am unable to understand. Can someone provide an explanation for what is an 
&gt; atomic operation

For a newbie?


**My understanding:** My understanding is that `atomic operation` means it executes fully with **no interruption**? Ie, it is a **blocking** operation with no scope of interruption?

What are atomic operations for newbies?

Every Modern OS provides today some atomic operations: 

- Windows has `Interlocked*` API
- FreeBSD has `&lt;machine/atomic.h&gt;`
- Solaris has `&lt;atomic.h&gt;`
- Mac OS X has `&lt;libkern/OSAtomic.h&gt;`

Anything like that for Linux?

- I need it to work on most Linux supported platforms including: x86, x86_64 and  **arm**.
- I need it to work on at least GCC and Intel Compiler.
- I need not to use 3rd par library like glib or qt.
- I need it to work in C++ (C not required)

Issues:

- GCC atomic builtins `__sync_*` are not supported on all platforms (ARM) and are not supported by the Intel compiler.
- AFAIK `&lt;asm/atomic.h&gt;` should not be used in user space and I haven&#39;t successfully used it at all. Also, I&#39;m not sure if it would work with Intel compiler.

**Any suggestions?**

I know that there are many related questions but some of them point to `__sync*` which is not feasible for me (ARM) and some point to `asm/atomic.h`.

Maybe there is an inline assembly library that does this for GCC (ICC supports gcc assembly)?

**Edit:** 

There is a very partial solution for add operations only (allows implementing atomic counter but not lock free-structures that require CAS):

If you use `libstc++` (Intel Compiler uses `libstdc++`) then you can use `__gnu_cxx::__exchange_and_add` that defined in `&lt;ext/atomicity.h&gt;` or `&lt;bits/atomicity.h&gt;`. Depends on compiler version.

However I&#39;d still like to see something that supports CAS.

How to perform atomic operations on Linux that work on x86, arm, GCC and icc?

I am trying to create a view where I save an object but I&#39;d like to _undo_ that save if some exception is raised. This is what I tried:

    class MyView(View):
    
        @transaction.atomic
        def post(self, request, *args, **kwargs):
            try:
                some_object = SomeModel(...)
                some_object.save()
    
                if something:
                    raise exception.NotAcceptable()
                    # When the workflow comes into this condition, I think the previous save should be undone
                    # What am I missing?
    
            except exception.NotAcceptable, e:
                # do something

What am I doing wrong? even when the exception is raised `some_object` is still in Database.

Django - Rollback save with transaction atomic

When return value is not of interest, is there any (even irrelevant in practice) difference between [`AtomicInteger.getAndIncrement()`][1] and [`AtomicInteger.incrementAndGet()`][2] methods, when return value is ignored?

I&#39;m thinking of differences like which would be more idiomatic, as well as which would put less load in CPU caches getting synchronized, or anything else really, anything to help decide which one to use more rationally than tossing a coin.

  [1]: http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/atomic/AtomicInteger.html#getAndIncrement%28%29
  [2]: http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/atomic/AtomicInteger.html#incrementAndGet%28%29

AtomicInteger.incrementAndGet() vs. AtomicInteger.getAndIncrement()

I am reading through Anthony Williams&#39; &quot;C++ Concurrency in Action&quot; and in Chapter 5, which talks about the new multithreading-aware memory model and atomic operations, and he states:

&gt; In order to use `std::atomic&lt;UDT&gt;` for some  user-defined `UDT`, this type must have a _trivial_ copy assignment operator.

As I understand it, this means that we can use `std::atomic&lt;UDT&gt;` if the following returns true:

    std::is_trivially_copyable&lt;UDT&gt;::value

By this logic, we shouldn&#39;t be able to use `std::string` as a template argument for `std::atomic` and have it work correctly.

However, the following code compiles and runs with expected output:

    #include &lt;atomic&gt;
    #include &lt;thread&gt;
    #include &lt;iostream&gt;
    #include &lt;string&gt;

    int main()
    {
    	std::atomic&lt;std::string&gt; atomicString;
    
    	atomicString.store( &quot;TestString1&quot; );
    
    	std::cout &lt;&lt; atomicString.load() &lt;&lt; std::endl;
    
    	atomicString.store( &quot;TestString2&quot; );
    
    	std::cout &lt;&lt; atomicString.load() &lt;&lt; std::endl;
    
    	return 0;
    }

Is this a case of undefined behaviour which just happens to behave as expected?

Thanks in advance!

Does std::atomic&lt;std::string&gt; work appropriately?

Often in internet I find that `LFENCE` makes no sense in processors x86, ie it does nothing , so instead `MFENCE` we can absolutely painless to use `SFENCE`, because `MFENCE` = `SFENCE` + `LFENCE` = `SFENCE` + `NOP` = `SFENCE`.

But if `LFENCE` does not make sense, then why we have four approaches to make Sequential Consistency in x86/x86_64:

1. `LOAD` (without fence) and `STORE` + `MFENCE`
2. `LOAD` (without fence) and `LOCK XCHG`
3. `MFENCE` + `LOAD` and `STORE` (without fence)
4. `LOCK XADD` ( 0 ) and `STORE` (without fence)

Taken from here: http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html

As well as performances from Herb Sutter on page 34 at the bottom: https://skydrive.live.com/view.aspx?resid=4E86B0CF20EF15AD!24884&amp;app=WordPdf&amp;wdo=2&amp;authkey=!AMtj_EflYn2507c

If `LFENCE` did not do anything, then the approach (3) would have the following meanings: `SFENCE + LOAD and STORE (without fence)`, but there is no point in doing `SFENCE` before `LOAD`. Ie if `LFENCE` does nothing , the approach (3) does not make sense.

Does it make any sense instruction `LFENCE` in processors x86/x86_64?

**ANSWER:**

**1.** `LFENCE` required in cases which described in the accepted answer, below.

**2.** The approach (3) should be viewed not independently, but in combination with the previous commands. For example, approach (3):

    MFENCE
    MOV reg, [addr1]  // LOAD-1
    MOV [addr2], reg  //STORE-1
    
    MFENCE
    MOV reg, [addr1]  // LOAD-2
    MOV [addr2], reg  //STORE-2

We can rewrite the code of approach (3) as follows:

    SFENCE
    MOV reg, [addr1]  // LOAD-1
    MOV [addr2], reg  //STORE-1
    
    SFENCE
    MOV reg, [addr1]  // LOAD-2
    MOV [addr2], reg  //STORE-2

And here `SFENCE` makes sense to prevent reordering  STORE-1 and LOAD-2. For this after STORE-1 command `SFENCE` flushes Store-Buffer.

Does it make any sense to use the LFENCE instruction on x86/x86_64 processors?

The java memory model mandates that writing a `int` is atomic: That is, if you write a value to it (consisting of 4 bytes) in one thread and read it in another, you will get all bytes or none, but never 2 new bytes and 2 old bytes or such.

This is not guaranteed for `long`. Here, writing `0x1122334455667788` to a variable holding `0` before could result in another thread reading `0x112233440000000` or `0x0000000055667788`.

Now the specification does not mandate object references to be either int or long-sized. For type safety reasons I suspect they are guaranteed to be written atomically, but on a 64bit VM these references could be very well 64bit values (merely memory addresses).

Now here are my questions:

  * Are there any memory model specs covering this (that I haven&#39;t found)?
  * Are long-writes suspect to be atomic on 64bit VMs?
  * Are VMs forced to map references to 32bit?

Regards,
  Steffen

Is writing a reference atomic on 64bit VMs

I am not being able to check this via experiments and could not gather it from the man pages as well. 

Say I have two processes, one moving(rename) file1 from directory1 to directory2. Say the other process running concurrently copies the contents of directory1 and directory2 to another location. Is it possible that the copy happens in such a way that both directory1 and directory2 will show file1 - i.e directory1 is copied before the move and directory2 after the move by the first process.

Basically is rename() is an atomic system call?


Thanks

Is rename() atomic?

I sort of understand that AtomicInteger and other Atomic variables allow concurrent accesses. In what cases is this class typically used though?




Practical uses for AtomicInteger

I understand that `std::atomic&lt;&gt;` is an atomic object. But atomic to what extent? To my understanding an operation can be atomic. What exactly is meant by making an object atomic? For example if there are two threads concurrently executing the following code:

    a = a + 12;

Then is the entire operation (say `add_twelve_to(int)`) atomic? Or are changes made to the variable atomic (so `operator=()`)? 

What exactly is std::atomic?

In general, for `int num`, `num++` (or `++num`), as a read-modify-write operation, is **not atomic**. But I often see compilers, for example [GCC][1], generate the following code for it ([try here][2]):

```c
void f()
{
  int num = 0;
  num++;
}
```

```assembly
f():
        push    rbp
        mov     rbp, rsp
        mov     DWORD PTR [rbp-4], 0
        add     DWORD PTR [rbp-4], 1
        nop
        pop     rbp
        ret
```

Since line 5, which corresponds to `num++` is one instruction, can we conclude that `num++` **is atomic** in this case?

And if so, **does it mean that so-generated `num++` can be used in concurrent (multi-threaded) scenarios without any danger of data races** (i.e. we don&#39;t need to make it, for example, `std::atomic&lt;int&gt;` and impose the associated costs, since it&#39;s atomic anyway)?

**UPDATE**

Notice that this question is *not* whether increment *is* atomic (it&#39;s not and that was and is the opening line of the question). It&#39;s whether it *can* be in particular scenarios, i.e. whether one-instruction nature can in certain cases be exploited to avoid the overhead of the `lock` prefix. And, as the accepted answer mentions in the section about uniprocessor machines, as well as [this answer][3], the conversation in its comments and others explain, **it can** (although not with C or C++).


  [1]: https://en.wikipedia.org/wiki/GNU_Compiler_Collection
  [2]: https://godbolt.org/g/UFKEvp
  [3]: https://stackoverflow.com/a/39414316/4973224

Can num++ be atomic for &#39;int num&#39;?

If there are two threads accessing a global variable then many tutorials say make the variable volatile to prevent the compiler caching the variable in a register and it thus not getting updated correctly.
However two threads both accessing a shared variable is something which calls for protection via a mutex isn&#39;t it? 
But in that case, between the thread locking and releasing the mutex the code is in a critical section where only that one thread can access the variable, in which case the variable doesn&#39;t need to be volatile?

So therefore what is the use/purpose of volatile in a multi-threaded program?

When to use volatile with multi threading?

I know that compound operations such as `i++` are not thread safe as they involve *multiple* operations. 

But is checking the reference with itself a thread safe operation?

    a != a //is this thread-safe

I tried to program this and use multiple threads but it didn&#39;t fail. I guess I could not simulate race on my machine.

EDIT:
-----

    public class TestThreadSafety {
    	private Object a = new Object();
    	
    	public static void main(String[] args) {
    	
    		final TestThreadSafety instance = new TestThreadSafety();
    		
    		Thread testingReferenceThread = new Thread(new Runnable() {
    
    			@Override
    			public void run() {
    				long countOfIterations = 0L;
    				while(true){
    					boolean flag = instance.a != instance.a;
    					if(flag)
    						System.out.println(countOfIterations + &quot;:&quot; + flag);
    					
    					countOfIterations++;
    				}
    			}
    		});
    		
    		Thread updatingReferenceThread = new Thread(new Runnable() {
    
    			@Override
    			public void run() {
    				while(true){
    					instance.a = new Object();
    				}
    			}
    		});
    
    		testingReferenceThread.start();
    		updatingReferenceThread.start();
    	}
    
    }

This is the program that I am using to test the thread-safety.

Weird behavior
--------------

As my program starts between some iterations I get the output flag value, which means that the reference `!=` check fails on the same reference. BUT after some iterations the output becomes constant value `false` and then executing the program for a long long time does not generate a single `true` output.

As the output suggests after some n (not fixed) iterations the output seems to be constant value and does not change. 

**Output:**

For some iterations:

    1494:true
    1495:true
    1496:true
    19970:true
    19972:true
    19974:true
    //after this there is not a single instance when the condition becomes true
     


Is the != check thread safe?

What is the difference between the `lazySet` and `set` methods of `AtomicInteger`? The [documentation][1] doesn&#39;t have much to say about `lazySet`:

&gt; Eventually sets to the given value.

It seems that the stored value will not be immediately set to the desired value but will instead be scheduled to be set some time in the future. But, what is the practical use of this method? Any example?


  [1]: http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/AtomicInteger.html#lazySet-int-

AtomicInteger lazySet vs. set

What is the difference between atomic and critical in OpenMP?

I can do this

&lt;!-- language: cpp --&gt;

	#pragma omp atomic
	g_qCount++;

but isn&#39;t this same as 

&lt;!-- language: cpp --&gt;

	#pragma omp critical
	g_qCount++;

?


What is the difference between atomic and critical in OpenMP?


In general, what can we take for granted when we append to a file in UNIX from multiple processes?  Is it possible to lose data (one process overwriting the other&#39;s changes)?  Is it possible for data to get mangled?  (For example, each process is appending one line per append to a log file, is it possible that two lines get mangled?)  If the append is not atomic in the above sense, then what&#39;s the best way of ensuring mutual exclusion?

Is file append atomic in UNIX?

In my multithreaded asmx web service I had a class field _allData of my own type SystemData which consists of few `List&lt;T&gt;` and `Dictionary&lt;T&gt;` marked as `volatile`. The system data (`_allData`) is refreshed once in a while and I do it by creating another object called `newData` and fill it&#39;s data structures with new data. When it&#39;s done I just assign 

    private static volatile SystemData _allData

    public static bool LoadAllSystemData()
    {
        SystemData newData = new SystemData();
        /* fill newData with up-to-date data*/
         ...
        _allData = newData.
    } 

This should work since the assignment is atomic and the threads that have the reference to old data keep using it and the rest have the new system data just after assignment. However my collegue said that instead of using `volatile` keyword and simple assigment I should use `InterLocked.Exchange` because he said that on some platforms it&#39;s not guaranteed that reference assignment is atomic. Moreover: when I declare `the _allData` field as `volatile` the 

    Interlocked.Exchange&lt;SystemData&gt;(ref _allData, newData); 

produces warning &quot;a reference to a volatile field will not be treated as volatile&quot; What should I think about this?

reference assignment is atomic so why is Interlocked.Exchange(ref Object, Object) needed?

Isn&#39;t `atomic&lt;bool&gt;` redundant because `bool` is atomic by nature? I don&#39;t think it&#39;s possible to have a partially modified bool value. When do I really need to use `atomic&lt;bool&gt;` instead of `bool`?

When do I really need to use atomic&lt;bool&gt; instead of bool?

    bool compare_exchange_weak (T&amp; expected, T val, ..);

`compare_exchange_weak()` is one of compare-exchange primitives provided in C++11. It&#39;s ***weak*** in the sense that it returns false even if the value of the object is equal to `expected`. This is due to ***spurious failure*** on some platforms where a sequence of instructions (instead of one as on x86) are used to implement it. On such platforms, context switch, reloading of the same address (or cache line) by another thread, etc can fail the primitive. It&#39;s `spurious` as it&#39;s not the value of the object (not equal to `expected`) that fails the operation. Instead, it&#39;s kind of timing issues.

But what puzzles me is what&#39;s said in C++11 Standard (ISO/IEC 14882),

&gt; 29.6.5
&gt; ..
&gt; A consequence of spurious failure is that nearly all uses of weak
&gt; compare-and-exchange will be in a loop.

Why does it have to be in a loop in ***nearly all uses*** ? Does that mean we shall loop when it fails because of spurious failures? If that&#39;s the case, why do we bother use `compare_exchange_weak()` and write the loop ourselves? We can just use `compare_exchange_strong()` which I think should get rid of spurious failures for us. What are the common use cases of `compare_exchange_weak()`?

Another question related. In his book &quot;C++ Concurrency In Action&quot; Anthony says,

    //Because compare_exchange_weak() can fail spuriously, it must typically
    //be used in a loop:
    
    bool expected=false;
    extern atomic&lt;bool&gt; b; // set somewhere else
    while(!b.compare_exchange_weak(expected,true) &amp;&amp; !expected);
    
    //In this case, you keep looping as long as expected is still false,
    //indicating that the compare_exchange_weak() call failed spuriously.

Why is `!expected` there in the loop condition? Does it there to prevent that all threads may starve and make no progress for some time?

**One last question**

On platforms that no single hardware CAS instruction exist, both the weak and strong version are implemented using LL/SC (like ARM, PowerPC, etc). So is there any difference between the following two loops? Why, if any? (To me, they should have similar performance.)

    // use LL/SC (or CAS on x86) and ignore/loop on spurious failures
    while (!compare_exchange_weak(..))
    { .. }
    
    // use LL/SC (or CAS on x86) and ignore/loop on spurious failures
    while (!compare_exchange_strong(..)) 
    { .. }

I come up w/ this last question you guys all mention that there maybe a performance difference inside a loop. It&#39;s also mentioned by the C++11 Standard (ISO/IEC 14882):

&gt; When a compare-and-exchange is in a loop, the weak version will yield
&gt; better performance on some platforms.

But as analyzed above, two versions in a loop should give the same/similar performance. What&#39;s the thing I miss?

Understanding std::atomic::compare_exchange_weak() in C++11

For something simple like a counter if multiple threads will be increasing the number. I read that mutex locks can decrease efficiency since the threads have to wait. So, to me, an atomic counter would be the most efficient, but I read that internally it is basically a lock? So I guess I&#39;m confused how either could be more efficient than the other. 

Which is more efficient, basic mutex lock or atomic integer?

What is the cost of the atomic operation (any of compare-and-swap or atomic add/decrement)? How much cycles does it consume? Will it pause other processors on SMP or NUMA, or will it block memory accesses? 
Will it flush reorder buffer in out-of-order CPU?

What effects will be on the cache?

I&#39;m interested in modern, popular CPUs: x86, x86_64, PowerPC, SPARC, Itanium.

atomic operation cost

What do `atomic` and `nonatomic` mean in property declarations?

    @property(nonatomic, retain) UITextField *userName;
    @property(atomic, retain) UITextField *userName;
    @property(retain) UITextField *userName;

What is the operational difference between these three?

What&#39;s the difference between the atomic and nonatomic attributes?

What operations in Java are considered atomic?

Can anyone explain what is `std::memory_order` in plain English, and how to use them with `std::atomic&lt;&gt;`?

I found the reference and few examples here, but don&#39;t understand at all.
http://en.cppreference.com/w/cpp/atomic/memory_order


c++, std::atomic, what is std::memory_order and how to use them?

If there a way to protect against concurrent modifications of the same data base entry by two or more users?

It would be acceptable to show an error message to the user performing the second commit/save operation, but data should not be silently overwritten.

I think locking the entry is not an option, as a user might use the &quot;Back&quot; button or simply close his browser, leaving the lock for ever.

Django: How can I protect against concurrent modification of database entries

If a data structure has multiple elements in it, the atomic version of it cannot (always) be lock-free.
I was told that this is true for larger types because the CPU can not atomically change the data without using some sort of lock.  

for example:

    #include &lt;iostream&gt;
    #include &lt;atomic&gt;

    struct foo {
        double a;
        double b;
    };

    std::atomic&lt;foo&gt; var;

    int main()
    {
        std::cout &lt;&lt; var.is_lock_free() &lt;&lt; std::endl;
        std::cout &lt;&lt; sizeof(foo) &lt;&lt; std::endl;
        std::cout &lt;&lt; sizeof(var) &lt;&lt; std::endl;
    }

the output (Linux/gcc) is:

    0
    16
    16

Since the atomic and `foo` are the same size, I don&#39;t think a lock is stored in the atomic.

My question is:  
If an atomic variable uses a lock, where is it stored and what does that mean for multiple instances of that variable ?


Where is the lock for a std::atomic?

I read a chapter and I didn&#39;t like it much. I&#39;m still unclear what the differences is between each memory order. This is my current speculation which I understood after reading the much more simple http://en.cppreference.com/w/cpp/atomic/memory_order

**The below is wrong so don&#39;t try to learn from it**

- memory_order_relaxed: Does not sync but is not ignored when order is done from another mode in a different atomic var
- memory_order_consume: Syncs reading this atomic variable however It doesnt sync relaxed vars written before this. However if the thread uses var X when modifying Y (and releases it). Other threads consuming Y will see X released as well? I don&#39;t know if this means this thread pushes out changes of x (and obviously y)
- memory_order_acquire: Syncs reading this atomic variable AND makes sure relaxed vars written before this are synced as well. (does this mean all atomic variables on all threads are synced?)
- memory_order_release: Pushes the atomic store to other threads (but only if they read the var with consume/acquire)
- memory_order_acq_rel: For read/write ops. Does an acquire so you don&#39;t modify an old value and releases the changes.
- memory_order_seq_cst: The same thing as acquire release except it forces the updates to be seen in other threads (if `a` store with relaxed on another thread. I store `b` with seq_cst. A 3rd thread reading `a`  with relax will see changes along with `b` and any other atomic variable?).

I think I understood but correct me if i am wrong. I couldn&#39;t find anything that explains it in easy to read english.


What do each memory_order mean?

From what I&#39;ve read from [Herb Sutter][1] and [others][2] you would think that `volatile` and concurrent programming were completely orthogonal concepts, at least as far as C/C++ are concerned.

However, in GCC [implementation][3] all of `std::atomic`&#39;s member functions have the `volatile` qualifier.  The same is true in Anthony Williams&#39;s [implementation][4] of `std::atomic`.

So what&#39;s deal, do my `atomic&lt;&gt;` variables need be `volatile` or not?

  [1]: http://herbsutter.wordpress.com/2009/01/12/effective-concurrency-volatile-vs-volatile/
  [2]: http://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/
  [3]: https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/files.html
  [4]: http://www.stdthread.co.uk/doc/headers/atomic/atomic.html

Why is the volatile qualifier used through out std::atomic?

From page 291 of OCP Java SE 6 Programmer Practice Exams, question 25:

    public class Stone implements Runnable {
        static int id = 1;
    
        public void run() {
            id = 1 - id;
            if (id == 0) 
                pick(); 
            else 
                release();
        }
    
        private static synchronized void pick() {
            System.out.print(&quot;P &quot;);
            System.out.print(&quot;Q &quot;);
        }
    
        private synchronized void release() {
            System.out.print(&quot;R &quot;);
            System.out.print(&quot;S &quot;);
        }
    
        public static void main(String[] args) {
            Stone st = new Stone();
            new Thread(st).start();
            new Thread(st).start();
        }
    }

One of the answers is:

&gt; The output could be `P Q P Q`

I marked this answer as correct. My reasoning:

1. We are starting two threads. 
2. First one enters `run()`.
3. According to [JLS 15.26.1](https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.26.1), it firstly evaluates `1 - id`. Result is `0`. It is stored on the thread&#39;s stack. We are just about to save that `0` to static `id`, but...
4. Boom, scheduler chooses the second thread to run.
5. So, the second thread enters `run()`. Static `id` is still `1`, so he executes method `pick()`. `P Q ` is printed.
6. Scheduler chooses first thread to run. It takes `0` from its stack and saves to static `id`. So, the first thread also executes `pick()` and prints `P Q `.

However, in the book it&#39;s written that this answer is incorrect:

&gt; It is incorrect because the line `id = 1 - id` swaps the value of `id` between `0` and `1`. There is no chance for the same method to be executed twice.

I don&#39;t agree. I think there is some chance for the scenario I presented above. Such swap is not atomic. Am I wrong?

Is id = 1 - id atomic?

Now that C++11 has multithreading I was wondering what is the correct way to implement lazy initialized singleton without using mutexes(for perf reasons).
I came up with this, but tbh Im not really good at writing lockfree code, so Im looking for some better solutions.

    // ConsoleApplication1.cpp : Defines the entry point for the console application.
    //
    # include &lt;atomic&gt;
    # include &lt;thread&gt;
    # include &lt;string&gt;
    # include &lt;iostream&gt;
    using namespace std;
    class Singleton
    {
    
    public:
    	Singleton()
    	{
    	}
    static	bool isInitialized()
    	{
    		return (flag==2);
    	}
    static	bool initizalize(const string&amp; name_)
    	{
    		if (flag==2)
    			return false;// already initialized
    		if (flag==1)
    			return false;//somebody else is initializing
    		if (flag==0)
    		{
    			int exp=0;
    			int desr=1;
    			//bool atomic_compare_exchange_strong(std::atomic&lt;T&gt;* obj, T* exp, T desr)
    			bool willInitialize=std::atomic_compare_exchange_strong(&amp;flag, &amp;exp, desr);
    			if (! willInitialize)
    			{
    				//some other thread CASed before us
    				std::cout&lt;&lt;&quot;somebody else CASed at aprox same time&quot;&lt;&lt; endl;
    				return false;
    			}
    			else 
    			{
    				initialize_impl(name_);
    				assert(flag==1);
    				flag=2;
    				return true;
    			}
    		}
    	}
    static void clear()
    {
    	name.clear();
    	flag=0;
    }
    private:
    static	void initialize_impl(const string&amp; name_)
    {
    		name=name_;
    }
    static 	atomic&lt;int&gt; flag;
    static  string name;
    };
    atomic&lt;int&gt; Singleton::flag=0;
    string Singleton::name;
    void myThreadFunction()
    {
    	Singleton s;
    	bool initializedByMe =s.initizalize(&quot;1701&quot;);
    	if (initializedByMe)
    		s.clear();
    	
    }
    int main()
    {
    	while (true)
    	{
    		std::thread t1(myThreadFunction);
    		std::thread t2(myThreadFunction);
    		t1.join();
    	    t2.join();
    	}
    	return 0;
    }
Note that `clear()` is just for testing, real singleton wouldnt have that function.


How to implement multithread safe singleton in C++11 without using &lt;mutex&gt;

C++11 introduced the [`std::atomic&lt;&gt;`][1] template library. The standard specifies the `store()` and `load()` operations to atomically set / get a variable shared by more than one thread.

My question is are assignment and access operations also atomic? 

Namely, is:

    std::atomic&lt;bool&gt; stop(false);
    ...
    void thread_1_run_until_stopped()
    {
        if(!stop.load())
            /* do stuff */
    }

    void thread_2_set_stop()
    {        
        stop.store(true);
    }

Equivalent to:

    void thread_1_run_until_stopped()
    {
        if(!stop)
            /* do stuff */
    }

    void thread_2_set_stop()
    {        
        stop = true;
    }


  [1]: http://en.cppreference.com/w/cpp/atomic/atomic

Must I call atomic load/store explicitly?

I am using Python to write chunks of text to files in a single operation:

    open(file, &#39;w&#39;).write(text)

If the script is interrupted so a file write does not complete I want to have no file rather than a partially complete file. Can this be done?


How to make file creation an atomic operation?

The C++11 standard defines a memory model (1.7, 1.10) which contains *memory orderings*, which are, roughly, &quot;sequentially-consistent&quot;, &quot;acquire&quot;, &quot;consume&quot;, &quot;release&quot;, and &quot;relaxed&quot;. Equally roughly, a program is correct only if it is race-free, which happens if all actions can be put in some order in which one action *happens-before* another one. The way that an action  *X happens-before* an action *Y* is that either *X* is sequenced before *Y* (within one thread), or *X inter-thread-happens-before Y*. The latter condition is given, among others, when

* *X* synchronizes with *Y*, or
* *X* is dependency-ordered before *Y*.

*Synchronizing-with* happens when *X* is an atomic store with &quot;release&quot; ordering on some atomic variable, and *Y* is an atomic load with &quot;acquire&quot; ordering on the same variable. Being *dependency-ordered-before* happens for the analogous situation where *Y* is load with &quot;consume&quot; ordering (and a suitable memory access). The notion of *synchronizes-with* extends the *happens-before* relationship transitively across actions being *sequenced-before* one another within a thread, but being *dependency-ordered-before* is extended transitively only through a strict subset of *sequenced-before* called *carries-dependency*, which follows a largish set of rules, and notably can be interrupted with `std::kill_dependency`.

Now then, what is the purpose of the notion of &quot;dependency ordering&quot;? What advantage does it provide over the simpler *sequenced-before* / *synchronizes-with* ordering? Since the rules for it are stricter, I assume that can be implemented more efficiently.

Can you give an example of a program where switching from release/acquire to release/consume is both correct and provides a non-trivial advantage? And when would `std::kill_dependency` provide an improvement? High-level arguments would be nice, but bonus points for hardware-specific differences.

How do &quot;acquire&quot; and &quot;consume&quot; memory orders differ, and when is &quot;consume&quot; preferable?

I wasn&#39;t aware of the `std::atomic` variables but was aware about the `std::mutex` (weird right!) provided by the standard; however one thing caught my eye: there are two seemingly-same (to me) atomic types provided by the standard, listed below:

1. [`std::atomic&lt;bool&gt;`](http://en.cppreference.com/w/cpp/atomic/atomic)

2. [`std::atomic_flag`](http://en.cppreference.com/w/cpp/atomic/atomic_flag)

The `std::atomic_flag` contains the following explanation:

&gt; `std::atomic_flag` is an atomic boolean type. Unlike all specializations of `std::atomic`, it is guaranteed to be lock-free. Unlike `std::atomic&lt;bool&gt;`, `std::atomic_flag` does not provide load or store operations.

which I fail to understand. Is `std::atomic&lt;bool&gt;` not guaranteed to be lock-free? Then it&#39;s not atomic or what?

So what&#39;s the difference between the two and when should I use which?

difference between standard&#39;s atomic bool and atomic flag

I have found `AtomicInteger`, `AtomicLong`, but where is `AtomicFloat` (or `AtomicDouble`)? Maybe there is some trick?

Java: is there no AtomicFloat or AtomicDouble?

How do atomic / volatile / synchronized work internally?

What is the difference between the following code blocks?

Code 1

    private int counter;
    
    public int getNextUniqueIndex() {
        return counter++; 
    }

Code 2

    private AtomicInteger counter;
    
    public int getNextUniqueIndex() {
        return counter.getAndIncrement();
    }

Code 3

    private volatile int counter;
    
    public int getNextUniqueIndex() {
        return counter++; 
    }

---

Does `volatile` work in the following way? Is

    volatile int i = 0;
    void incIBy5() {
        i += 5;
    }

equivalent to 

    Integer i = 5;
    void incIBy5() {
        int temp;
        synchronized(i) { temp = i }
        synchronized(i) { i = temp + 5 }
    }


I think that two threads cannot enter a synchronized block at the same time... am I right? If this is true then how does `atomic.incrementAndGet()` work without `synchronized`? And is it thread-safe?

And what is the difference between internal reading and writing to volatile variables / atomic variables? I read in some article that the thread has a local copy of the variables - what is that?

What is the difference between atomic / volatile / synchronized?

In the Effective Java book, it states: 

&gt; The language specification guarantees that reading or writing a
&gt; variable is atomic unless the variable is of type `long` or `double` [JLS,
&gt; 17.4.7].

What does &quot;atomic&quot; mean in the context of Java programming, or programming in general?

What does &quot;atomic&quot; mean in programming?

Are C/C++ fundamental types, like `int`, `double`, etc., atomic, e.g. threadsafe?

Are they free from data races; that is, if one thread writes to an object of such a type while another thread reads from it, is the behavior well-defined?

If not, does it depend on the compiler or something else?


Are C/C++ fundamental types atomic?

I am wondering what the `atomically:` parameter stands for in the `writeToFile:atomically:` method (`-[NSArray writeToFile:atomically:]` for example). It is common to pass `YES` for `atomically:`, but I don&#39;t know what it means.

writeToFile:atomically: what does atomically mean?

I&#39;ve looked at the other volatile vs. Atomicxxxx questions in SO (including [this one][1]) and have read [the description of java.util.current.atomic][2], and I am not quite satisfied with the nuances.

If I&#39;m trying to decide between using `volatile boolean` and `AtomicBoolean`, are there practical differences besides the atomic read-modify-write operations offered by AtomicBoolean? (e.g. `compareAndSet()` and `getAndSet()`)

Suppose I have

    volatile boolean flag;

Then one or more threads set the flag (but not clear it). If I have one thread that reads the flag, and if set, does an action, and then clears the flag, is `volatile` adequate?

Is there a higher cost to AtomicBoolean than volatile boolean, in terms of

 - memory space
 - performance hit (`volatile boolean` appears to require memory fencing, `AtomicBoolean` appears to require memory fencing + some minor locking on CAS operations as per the java.util.current.atomic description)

My gut call is to just go with AtomicBoolean and be safe, but I want to understand if there&#39;s ever a situation to use `volatile boolean` instead (e.g. if I had thousands of instances of them and performance were an issue).

  [1]: https://stackoverflow.com/questions/3786825/java-volatile-boolean-vs-atomicboolean
  [2]: http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/atomic/package-summary.html

When is it preferable to use volatile boolean in Java rather than AtomicBoolean?

Is there a systematic way to know whether an operation in C# will be atomic or not?  Or are there any general guidelines or rules of thumb?

What operations are atomic in C#?

I get that at the assembly language level instruction set architectures provide compare and swap and similar operations. However, I don&#39;t understand how the chip is able to provide these guarantees.

As I imagine it, the execution of the instruction must

1. Fetch a value from memory
2. Compare the value
3. Depending on the comparison, possibly store another value in memory

What prevents another core from accessing the memory address after the first has fetched it but before it sets the new value? Does the memory controller manage this?

edit: If the x86 implementation is secret, I&#39;d be happy to hear how any processor family implements it.

All Atomic Solutions on Gang of Coders

Total of 42 Atomic Solutions