I am in a suitation where i have to use static variable for multiple threads. Is there is any alternate methods which can work for the same. Kindly ignores ridiculousness.
Threads are also functions fundamentally.
So static variable will have same behavior in terms of threads as how it works with normal fucntions.
Because static variable stores in a section of process other than the stack segment , any change in static variable in one thread will reflect in another thread.
Related
Basically, the title is self-explanatory.
I use it in following way:
The code is in Objective-C++.
Objective-C classes make concurrent calls to different purpose functions.
I use std::mutex to lock and unlock std::vector<T> editing option across entire class, as C++ std containers are not thread safe.
Using lock_guard automatically unlocks the mutex again when it goes out of scope. That makes it impossible to forget to unlock it, when returning, or when an exception is thrown. You should always prefer to use lock_guard or unique_lock instead of using mutex::lock(). See http://kayari.org/cxx/antipatterns.html#locking-mutex
lock_guard is an example of an RAII or SBRM type.
The std::lock_guard is only used for two purposes:
Automate mutex unlock during destruction (no need to call .unlock()).
Allow simultaneous lock of multiple mutexes to overcome deadlock problem.
For the last use case you will need std::adopt_lock flag:
std::lock(mutex_one, mutex_two);
std::lock_guard<std::mutex> lockPurposeOne(mutex_one, std::adopt_lock);
std::lock_guard<std::mutex> lockPurposeTwo(mutex_two, std::adopt_lock);
On the other hand, you will need allocate yet another class instance for the guard every time you need to lock the mutex, as std::lock_guard has no member functions. If you need guard with unlocking functionality take a look at std::unique_lock class. You may also consider using std::shared_lock for parallel reading of your vector.
You may notice, that std::shared_lock class is commented in header files and will be only accessible with C++17. According to header file you can use std::shared_timed_mutex, but when you will try to build the app it will fail, as Apple had updated the header files, but not the libc++ itself.
So for Objective-C app it may be more convenient to use GCD, allocate a couple of queue for all your C++ containers at the same time and put semaphores where needed. Take a look at this excellent comparison.
I've read a lot about thread safety when reading variable simultanously from multiple threads but I am still not sure whether my case is fine or not.
Consider that I have:
const
MySettings: TFormatSettings =
(
CurrencyFormat : 0;
NegCurrFormat : 0;
ThousandSeparator: ' ';
DecimalSeparator : '.';
CurrencyString : 'ยค';
ShortDateFormat : 'MM/dd/yyyy';
LongDateFormat : 'dddd, dd MMMM yyyy';
//All fields of record are initialized.
);
Can I use FormatDateTime('dd/mm/yyyy hh:nn:ss', MySettings, Now) in multiple threads without worries or should I spawn a separate copy of MySettings for each thread?
This scenario is threadsafe if and only if the format settings record is not modified during the simultaneous calls to formatting functions.
Indeed the old school formatting functions that used a shared global format settings record were threadsafe if and only if the shared object was not modified. This is the key point. Is the format settings object modified or not?
My take on all this is that you should avoid modifying format settings objects. Initialise them and then never modify them. That way you never have thread safety issues.
Yes this is perfectly safe.
As long as MySetting is not changed this is the way to use FormatDateTime and other similar procedures.
From documentation, System.SysUtils.TFormatSettings:
A variable of type TFormatSettings defines a thread-safe context that formatting functions can use in place of the default global context, which is not thread-safe.
N.B. You must provide this thread-safe context by programming. It is thread-safe only if you ensure that the parameter and its shares is not changed during execution.
Typically my serializing libraries are using a shared constant format setting variable, which provides a stable read/write interface in all locales.
When I create a new thread in a program... in it's thread handle function, why do I pass variables that I want that thread to use through the thread function prototype as parameters (as a void pointer)? Since threads share the same memory segments (except for stack) as the main program, shouldn't I be able to just use the variables directly instead of passing parameters from main program to new thread?
Well, yes, you could use the variables directly. Maybe. Assuming that they aren't changed by some other thread before your thread starts running.
Also, a big part of passing parameters to functions (including thread functions) is to limit the amount of information the called function has to know about the outside world. If you pass the thread function everything it needs in order to do its work, then you can change the rest of the program with relative impunity and the thread will still continue to work. If, however, you force the thread to know that there is a global list of strings called MyStringList, then you can't change that global list without also affecting the thread.
Information hiding. Encapsulation. Separation of concerns. Etc.
You cannot pass parameters to a thread function in any kind of normal register/stack manner because thread functions are not called by the creating thread - they are given execution directly by the underlying OS and the API's that do this copy a fixed number of parameters, (usually only one void pointer), to the new and different stack of the new thread.
As Jim says, failure to understand this mechanism often results in disaster. There are numnerous questions on SO where the vars that devs. hope would be used by a new thread are RAII'd away before the new thread even starts.
I am reading the concept of language ch 5 and find that
static's disadvantage : subprograms cannot share same storage.
stack-dynamic's advantage : without recursion, it is not without merit subprograms can share the same memory space for theirs locals.
and I think that due to static bound from begin to terminal, all subprogram should can see it and use
it
like the code I test
#include<iostream>
static int test = 0;
void func1(){ cout << test++ << endl;}
void func2(){ cout << test++ << endl;}
int main(){
func1();
func2();
}
and stack-dynamic allocation each time execute the function, like being push to stack(LIFO), so they
are in different momory space.
I don't know where is the error in my thought?
Thx in advance.
You program runs in a dedicated memory space.
Static variables have global scope.
Given that, I suppose "Subprograms cannot share same storage" means that static variable is instantiated only once and it's the same object during the entire lifetime of the program.
This has several consequences:
If your independent functions need storage as part of their execution, they shouldn't address the same static variables because they will affect the other functions using the same variables.
If your functions can run in parallel (e.g. on several processors) and they address same static variables, these variable become a shared resource, meaning it must be protected against parallel access (which can corrupt the data and result in incorrect behavior).
Dynamically allocated/stack variables use the same memory space in which the program runs, but they can be instantiated many times, and the instances are independent of each other. E.g., if stack variable is defined inside a function, it's allocated upon function entry and released upon function exit. If the function is entered again, new variable will be created. It's same memory space, but different stack frame in this space.
I always had this specific scenario worry me for eons. Let's say my class looks like this
public class Person {
public Address Address{get;set;}
public string someMethod()
{}
}
My question is, I was told by my fellow developers that the Address propery of type Address, is not thread safe.
From a web request perspective, every request is run on a separate thread and every time
the thread processes the following line in my business object or code behind, example
var p = new Person();
it creates a new instance of Person object on heap and so the instance is accessed by the requesting thread, unless and otherwise I spawn multiple threads in my application.
If I am wrong, please explain to me why I am wrong and why the public property (Address) is not thread safe?
Any help will be much appreciated.
Thanks.
If the reference to your Person instance is shared among multiple threads then multiple threads could potentially change Address causing a race condition. However unless you are holding that reference in a static field or in Session (some sort of globally accessible place) then you don't have anything to be worried about.
If you are creating references to objects in your code like you have show above (var p = new Person();) then you are perfectly thread safe as other threads will not be able to access the reference to these objects without resorting to nasty and malicious tricks.
Your property is not thread safe, because you have no locking to prevent multiple writes to the property stepping on each others toes.
However, in your scenario where you are not sharing an instance of your class between multiple threads, the property doesn't need to be thread safe.
Objects that are shared between multiple threads, where each thread can change the state of the object, then all state changes need to be protected so that only one thread at a time can modify the object.
You should be fine with this, however there are a few things I'd worry about...
If your Person object was to be modified or held some disposable resources, you could potentially find that one of the threads will be unable to read this variable. To prevent this, you will need to lock the object before read/writing it to ensure it won't be trampled on by other threads. The easiest way is by using the lock{} construct.