Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Thread Safety: Lock vs Reference

I have a C# program that has a list that does writes and reads in separate threads. The write is user initiated and can change the data at any random point in time. The read runs in a constant loop. It doesn't matter if the read is missing data in any given loop, as long as the data it does receive is valid and it get's the new data in a future loop.

After considering ConcurrentBag, I settled on using locks for a variety of reasons (simplicity being one of them). After implementing the locks, a coworker mentioned to me that using temporary references to point to the old List in memory would work just as well, but I am concerned about what will happen if the new assignment and the reference assignment would happen at the same time.

Q: Is the temporary reference example below thread safe?

Update: User input provides a list of strings which are used in DoStuff(). You can think of these strings as a definition of constants and as such the strings need to be persisted for future loops. They are not deleted in DoStuff(), only read. UserInputHandler is the only thread that will ever change this list and DoStuff() is the only thread that will ever read from this list. Nothing else has access to it.

Additionally, I am aware of the the Concurrent namespace and have used most of the collections in it in other projects, but, I have chosen not to use them here because of extra code complexity that they add (i.e. ConcurrentBag doesn't have a simple Clear() function, etc.). A simple lock is good enough in this situation. The question is only whether the second example below is thread safe.


Lock

static List<string> constants = new List<string>();

//Thread A
public void UserInputHandler(List<string> userProvidedConstants)
{
    lock(items)
    {
        items.Clear();
        foreach(var constant in userProvidedConstants)
        {
            constants.Add(constant);
        }
    }
}

//Thread B
public void DoStuff()
{
    lock(items)
    {
        //Do read only actions with items here
        foreach(var constant in constants)
        {
            //readonly actions
        }
    }
}

Reference

static List<string> constants = new List<string>();

//Thread A
public void UserInputHandler(List<string> userProvidedConstants)
{
    lock(items)
    {
        items = new List<string>();
        foreach(var constant in userProvidedConstants)
        {
            constants.Add(constant);
        }
    }
}

//Thread B
public void DoStuff()
{
    var constantsReference = constants;

    //Do read only actions with constantsReference here
    foreach(var constant in constantsReference)
    {
        //readonly actions
    }
}
like image 570
lolcodez Avatar asked Jun 06 '14 18:06

lolcodez


People also ask

When should I worry about thread safety?

Save this answer. Show activity on this post. Thread safety becomes a concern if there is at least a single entry point which can be accessed by multiple threads. If a piece of code is accessed by multiple threads and is calling other method/class/etc., then all this code tree becomes vulnerable.

What is meant by thread safety?

Thread safety is the avoidance of data races—situations in which data are set to either correct or incorrect values, depending upon the order in which multiple threads access and modify the data. When no sharing is intended, give each thread a private copy of the data.

Does rust guarantee thread safety?

Rust guarantees thread safety using similar concepts for memory safety and provides standard library features like channels, mutex, and ARC (Atomically Reference Counted) pointers. In safe Rust, you can have either one mutable reference to a value or unlimited read-only references to it at any given time.

Is lock thread-safe?

No, it's not thread safe. Add and Count may be executed at the "same" time. You have two different lock objects. Save this answer.


1 Answers

This is not safe without the lock. Copying the reference to the list doesn't really do anything for you in this context. It's still quite possible for the list that you are currently iterating to be mutated in another thread while you are iterating it, causing all sorts of possible badness.

like image 72
Servy Avatar answered Oct 24 '22 22:10

Servy