ThreadLocal IsValueCreated Returns True Forever; Even With No Factory

[steevcoco]

Description

Creating a ThreadLocal with no factory; then setting the Value property non-null, will return true from IsValueCreated. Then setting the Value null; it still returns true from IsValueCreated.

The same does happen for an instance with a factory.

Reproduction Steps

using System;
using System.Threading;


public class Program
{
    private static ThreadLocal<object> manual = new();
    private static ThreadLocal<object> factory = new(() => new());


    public static void Main()
    {
        Console.WriteLine("\"Manual\":");
        Console.WriteLine(manual.IsValueCreated); // False
        manual.Value = new();
        Console.WriteLine(manual.IsValueCreated); // True
        manual.Value = null;
        Console.WriteLine(manual.IsValueCreated); // Still true!

        Console.WriteLine();

        Console.WriteLine("\"Factory\":");
        Console.WriteLine(factory.IsValueCreated); // False
        _ = factory.Value;
        Console.WriteLine(factory.IsValueCreated); // True
        factory.Value = null;
        Console.WriteLine(factory.IsValueCreated); // Still true!
    }
}

Expected behavior

When the ThreadLocal is initialized with no factory, and all usage has been by manually setting the Value; it seems inconsistent.

Using a factory, it does seem inconsistent; at least if the documentation does not say "returns true the first time the Value is created; and stays true".

Actual behavior

The way the class is documented, it simply seems that the property should return the current state of the Value all the time.

Regression?

Happens in .net 8 and also net48.

Known Workarounds

Do not use IsValueCreated at all; or otherwise you must set the value once and never change it.

Configuration

No response

Other information

No response

[dotnet-policy-service]

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

[colejohnson66]

It’s true because the value was set. It does not track nulls, just that it was ever set. If you want to know if the value is null, just compare it to null.

[steevcoco]

OK: I have wrapped my head around that. It might be nice if the documentation mentioned that.

[colejohnson66]

I don't know how the documentation for IsValueCreated could really be improved? It says the value is "true if Value is initialized on the current thread; otherwise false." Initialized does not mean "non-null" as some properly initialized objects could be null (such as if not present).

The documentation for Value says that "if this instance was not previously initialized for the current thread, accessing Value will attempt to initialize it. If an initialization function was supplied during the construction, that initialization will happen by invoking the function to retrieve the initial value for Value. Otherwise, the default value of T will be used." In other words, you will get null if the value is uninitialized, but null does not imply the value is uninitialized.

In mathematical terms:

NOT(init) ---> NULL
   NULL   -/-> NOT(init)

However, you drew the inference:

NOT(init) ---> NULL
   NULL   ---> NOT(init)

[colejohnson66]

I proposed a documentation change to possibly help clarify this situation.

[steevcoco]

Sorry: I simply would suppose it should then just follow other Nullable documentation styles ... The Value Type IS unbounded; and then IsValueCreated WOULD IN FACT return what should be expected, for a default Value Type too. It's merely able to infer something like "Has the Value been 'Set'". ... I get it!