What does a function being thread-safe means with regards to its arguments?

My current understanding of thread safety is that:

• A function is thread-safe if any existing functions (including itself) can be run concurrently in other threads without unintended interaction
• A type is thread-safe if it doesn't directly expose its internals and if the functions making up its public interface are thread-safe

Which I basically took to mean that:

• Logic must account for possible other threads
  • A thread-safe function must assume that all information is immediately stale unless it takes steps to ensure it is not
  • A thread-safe type's interface should avoid preconditions that could be invalidated between the user checking them and calling the function
• Access to any member/static/global variable in a thread-safe function must either be read-only (if it's immutable) or be protected (e.g. by mutexes)

I thought that covered everything, but then I ran into a function of the form:

template <typename IteratorType>
void performSomeOperationOnARange(IteratorType const& itBegin, IteratorType const& itEnd);

• This function doesn't access any member/static/global variable, so I want to consider it thread-safe
• Running it concurrently on the same range definitely leads to unintended interaction though, so I'm tempted to consider it unsafe
• That being said, it seems unreasonable to expect the function to protect access to data it knows nothing about
• Extending that into a full principle, that would mean that protecting access to a function's arguments should fall to the caller, not the callee
• This however feels too broad. this is an argument passed to every non-static member function (albeit implicitly), and in that case ensuring that access to member variables is safe definitely falls to the callee

Hence the question in the title: What does a function being thread-safe means with regards to its arguments? Where do you draw the line between the responsibility of the caller and the callee?

Your understanding of thread safety and its implications on functions and types is generally correct. However, when it comes to the thread safety of function arguments, the answer depends on the context in which the function is being used.

In general, a function should assume that its arguments are not thread-safe unless explicitly documented otherwise. This means that if a function takes a pointer or reference to an object that may be accessed concurrently by multiple threads, it should be the responsibility of the caller to ensure that the object is protected or synchronized appropriately.

In your specific example, the function performSomeOperationOnARange takes iterators as arguments, which are typically lightweight objects that don't carry any thread-safety guarantees. It is up to the caller to ensure that the range being passed to the function is not being accessed concurrently by other threads. If the range is being shared between threads, the caller should synchronize access to the range using a mutex or other synchronization mechanism.

On the other hand, if a function takes a pointer or reference to an object that is guaranteed to be thread-safe, such as an immutable object or a thread-safe container, the function can be considered thread-safe as well.

In general, the responsibility for ensuring thread safety should be clearly documented and communicated between the caller and callee, especially if the function is part of a public interface or API.