4
$\begingroup$

I'm working on a graph representation of software for a static analysis project, and I'm finding a distinction that I have no name for between different types of variables.

On one side of the division, we have local variables and parameters, which are not subject to modification by other threads during the execution of a method. For these variables, static single assignment form is valid.

On the other side of the division, we have global variables, fields, and C/C++ static local variables, which can be modified by other threads, meaning static single assignment form is not necessarily valid, as the variable may be modified by a separate thread during the execution of the method.

Is there any existing term for this division?

Improve this question
$\endgroup$
8
  • 1
    $\begingroup$ Maybe "thread local" for stack allocatable storage and "not thread local" otherwise. But I don't understand what "fields" you are referring to. Should not a field of a struct, record or object have the same scope and lifetime as the struct that contains it? $\endgroup$
    – Wandering Logic
    Commented May 1, 2014 at 0:02
  • $\begingroup$ I'm also not convinced that local vars are as immune to sharing as you imply, unless you are considering every variable that gets its address taken as global. $\endgroup$
    – Wandering Logic
    Commented May 1, 2014 at 0:07
  • $\begingroup$ Quick search leads to this wiki page: en.wikipedia.org/wiki/Thread-local_storage. However, it does not mention anything about heap variable. Usually, heap variables can be modified by any threads. $\endgroup$
    – Tushar
    Commented May 1, 2014 at 2:36
  • $\begingroup$ @WanderingLogic Yes, the lifetime of a field is the same as the lifetime of an object it belongs to...I suppose that does mean stack allocated structs and objects are also thread-local if not passed by address/reference, which I hadn't taken time to consider. $\endgroup$
    – Theodore Murdock
    Commented May 1, 2014 at 5:00
  • 1
    $\begingroup$ Also, I agree that taking the address of a variable does generally invalidate it as a candidate for static single assignment form. A quick search also confirms it's not unheard of to pass pointers to stack variables to trusted code in a separate thread and then block until that code is known to no longer retain a reference to the stack location. $\endgroup$
    – Theodore Murdock
    Commented May 1, 2014 at 5:07

2 Answers 2

Reset to default
3
$\begingroup$

One standard term is "shared mutable state".

Let's unpack that. "State" is any place to store data: e.g., a variable or object. "Mutable" means that the data can be modified. "Shared" means it is shared among multiple threads. Thus, shared mutable state is state that is visible to multiple threads and can be modified by multiple threads.

Usually, immutable state is not a concern: even if it can be read by multiple threads, no one can write to it, so there is no potential for data races or concurrence problems.

Usually, non-shared state is not a concurrency concern: there's only a single thread that can read or write it, so we don't have to worry about concurrency -- merely single-threaded-correctness.

Note that this also helps clarify how we should think about a case that wasn't mentioned in your original question. What about state that can only be written by a single thread, but can be viewed by multiple threads? That's shared mutable state. And that's exactly the right classification, because such state can cause concurrency problems: if you're not careful, it can cause data races and other issues, so it's only right that it be lumped together with other kinds of shared mutable state.

(For instance, in your question you write that "local variables... are not subject to modification by other threads during the execution of a method". This is true, but it doesn't go far enough. The relevant fact about local variables is that they can't be modified or read by other threads. Also, this highlights that not all local variables qualify: for instance, if you take the address of the local variable and pass that pointer to another thread, the local variable now becomes shared mutable state and is a concurrency problem.)

Improve this answer
$\endgroup$
1
$\begingroup$

As Wandering Logic already mentioned in the comments, the most obvious distinction in your case is thread-local storage vs non-thread-local storage.

In general, the specification of your programming language of choice should have a section about storage duration and visibility of variables. For C++ the rules are rather complicated. You can have a look at this summary.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.