Question regarding freshness of volatile reading of a value written with Interlocked

[AqlaSolutions]

Let's look at this code

class TaskTracker
{
    private volatile ConcurrentBag<Task> _bag = new();
    
    public async Task WaitAllAvailableAsync()
    {
        await Task.WhenAll(Interlocked.Exchange(ref _bag, new()));
    }


    // should guarantee that the Task will be awaited on at least one WaitAllAvailableAsync call
    public void AddTask(Task toWait)
    {
        ConcurrentBag<Task> oldBag, bag = _bag;
        do
        {
            bag.Add(toWait);
            oldBag = bag;
        } while ((bag = _bag) != oldBag);
    }
}

This class allows its user to add tasks to the internal list. When the WaitAllAvailableAsync is called, all currently added tasks are removed from the list and awaited. This may be used as a barrier mechanism to wait for all already started incoming requests to complete (without blocking adding newer requests). Both methods are thread safe and can be used from any number of threads.

I'm not sure about the guarantees applied to this line:

} while ((bag = _bag) != oldBag);

Image that Interlocked.Exchange( have already executed at this point and another instance of bag was written. Does volatile read of _bag really guarantees seeing the new value? Would Interlocked.CompareExchange(ref _bag, null, null) provide better guarantees?

I saw many different opinions on SO about the difference between Interlocked and volatile non-caching guarantees. Some people say that volaile only prevents reordering, others say that it also ensures reading somewhat fresh value but it can be stale by a few milli/nanoseconds. For the code above reading any stale value can lead to that the task will be added to an already discarded _bag instance and thus the task will never be awaited. I'm not sure whom to believe so I decided to ask here.

I know that this code may be rewritten without volatile by using ConcurrentQueue but here I'm trying to understand specifically the behavior of volatile read in this example.

Similar issue #67330 doesn't have the answer suitable here.

[ghost]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Let's look at this code

class TaskTracker
{
    private volatile ConcurrentBag<Task> _bag = new();
    
    public async Task WaitAllAvailableAsync()
    {
        await Task.WhenAll(Interlocked.Exchange(ref _bag, new()));
    }


    // should guarantee that the Task will be awaited on at least one WaitAllAvailableAsync call
    public void AddTask(Task toWait)
    {
        ConcurrentBag<Task> oldBag, bag = _bag;
        do
        {
            bag.Add(toWait);
            oldBag = bag;
        } while ((bag = _bag) != oldBag);
    }
}

This class allows its user to add tasks to the internal list. When the WaitAllAvailableAsync is called, all currently added tasks are removed from the list and awaited. This may be used as a barrier mechanism to wait for all already started incoming requests to complete (without blocking adding newer requests). Both methods are thread safe and can be used from any number of threads.

I'm not sure about the guarantees applied to this line:

} while ((bag = _bag) != oldBag);

Image that Interlocked.Exchange( have already executed at this point and another instance of bag was written. Does volatile read of _bag really guarantees seeing the new value? Would Interlocked.CompareExchange(ref _bag, null, null) provide better guarantees?

I saw many different opinions on SO about different between Interlocked and volatile non-caching guarantees. Some people say that volaile only prevents reordering, others say that is also ensures reading somewhat fresh value but it can be stale by a few milli/nanoseconds. For the code above reading any stale value can lead to that the task will be added to an already discarded _bag instance and thus the task will never be awaited. I'm not sure whom to believe so I decided to ask here.

I know that this code may be rewritten without volatile by using ConcurrentQueue but here I'm trying to understand specifically the behavior of volatile read in this example.

Author:	AqlaSolutions
Assignees:	-
Labels:	area-System.Threading
Milestone:	-