Allow "locked members" in C# to make sure that no other thread executes or uses it at the same time

[jcouv]

@TheFanatr commented on Wed Dec 13 2017

I am working on a project that, due to speed requirements, needs to be multithreaded; however, the majority of the members in some of the classes I am writing need to be locked with the C# "lock(object x)" statement so that the value of something isn't changed in the middle of a method execution on another thread. This means that I need to create a static lock object for every class that needs it, and add lock(lock) { /* code */ } to every member that needs to be locked. This just clutters everything, and doesn't need to. Multithreading is used a lot, and most of the times requires that members be thread-safe; there should be an easier and/or less wasteful way to make this possible. My proposal is that the following syntax should be allowed to achieve the same functionality:

// No other thread can get or set this while it's being gotten or set.
public locked int DisplayCode { get => /* calculate or find display code */; set => /* cache display code */; }  

// No other thread can get this while it's being gotten.
public locked double CurrentFolder => /* code to get current folder */;

// No other thread can set this while it's being gotten or set;
public locked bool DeepTraverse { get; set; } = false;

// No other thread can get or set this while it's being set.
public locked bool _IgnoreSystemFiles = true;

// No other thread can use this method while it's being executed.
public locked string RenameDirectory() => throw new NotImplementedException { };

// All the members in this class are locked
internal locked class RegistryUtilities
{
    // This member is unlocked.
    internal unlocked int RandomNumberSeed { get; set; }

    // The active location cannot be set while being modified or accessed by another thread.
    internal string ActiveLocation { get; set; }

    // get is unlocked while set isn't.
    internal unlocked string CurrentDirectoryFullName { get; locked set; } // Get and set have implementations

    // Same deal as the locked method outside of this class.
    internal bool RenameKey(string keyName)
    {
        /* code */
        /* more code */
    } 
}

---

I realize that there may be consistency or logic issues with the proposal, but I as well as probably many others would really appreciate some kind of system to do this. It would save a lot of time and clutter. Also, note that the provided code sample isn't real code, I just came up with it to show what I mean.

---

@jcouv commented on Wed Dec 13 2017

Moving language design discussions to csharplang. Thanks

[yaakov-h]

Duplicate of #892?

[HaloFour]

This means that I need to create a static lock object for every class that needs it

You create a static lock object? As in writing to any once instance will block writing to any other instance?

You don't have to create a separate lock object. You can just lock on the instance of the class. Or, since you have very coarse lock granularity, the Type of the class itself. Although I technically wouldn't recommend either since that would expose the lock primitive which can allow for an outside actor to acquire/hold inappropriately.

The CLR was designed to support synchronized methods. You can apply it via the MethodImplAttribute. But despite that C# never allowed for synchronized methods through the language. Not having been in the room I can't exactly state why that is, but if I were to guess it would probably be because Java demonstrated why it wasn't a good idea. There are several problems with it in Java. First, as mentioned above, it exposes the lock primitives. Second, synchronization is inherently policy heavy. It's rarely so coarsely granular as method-wide, and especially not every-method-wide. But without a lot of additional language there's no real way to convey that certain methods lock in groups. This is why, even in Java, when I want something as simple as blocking threads, I rely on creating my own lock instances and using synchronized on them within the method body only where necessary. Although honestly there's almost always a better way to achieve thread-safety through exploring other synchronization primitives.