I need to set a flag in a secondary thread started in a form and read it into a method of another form.
How do i could make it?
Printable View
I need to set a flag in a secondary thread started in a form and read it into a method of another form.
How do i could make it?
Use events and a custom delegate with a special parameter (your value).
You can use common property of a class. I suggest you to create your own class for that purpose. If you want to be sure that it is thread safe, use the lock keyword.
For example:
Code:public class Model
{
private object obj;
public object Value
{
get { lock (this) return this.obj; }
set { lock (this) this.obj = value; }
}
}
In general, locking on 'this' is *not* recommended simply because it's too easy to create deadlocks. Also, that's not really threadsafe. It's what you *do* with the 'Value' that matters.Quote:
Originally Posted by boudino
It should be
If the above example, you can have 1,000 threads running the 'ThreadedMethod' but access to the 'Model' object declared at the top is completely threadsafe. The previous example provides no threadsafety in the use of the object.Code:
Model m = new Model(); // All threads can access this model
object locker = new object(); // all threads can access this lock object
public void ThreadedMethod()
{
DoStuff();
lock(locker)
{
DoOperation(m.Value);
DoOtherOperation(m.Value);
}
DoMoreStuff();
}
Maybe you are true, but can you provide a more verbose explanation, please? I don't fully understood you. If I read your sample well, you are locking outside the model, so the m.Value can be still accessed thread unsafe from other code than ThreadedMethod().
In your example, if i call:
object o = m.Value
and then i start using 'o' to do work, every thread can be using 'o' to do work simultaneously. That's the definition of non-threadsafe access ;) If it's ok to be using o in a non-threadsafe way, then that's fine. However since the point of the example was to show how to have threadsafe access, it's not a good example.
Welcome to the world of threaded programming. Every time you want to safely acces m.Value you need to make sure you take out the lock on the same object that other threads will be using.Quote:
If I read your sample well, you are locking outside the model, so the m.Value can be still accessed thread unsafe from other code than ThreadedMethod().
Lets assume m.Value returns a database connection and it can only support 1 simultaenous query at a time. In that case, your code (which just protects the getter and setter) would break horribly as every thread would just use the connection immediately. In my code, every time any thread wants to use the database connection, it must take out the lock on the object, and then it uses the connection. No breakage :)
If I make this:
I Could to instance this class into differents threads and It will work safe?Code:class MyThreadLink
{
private static Boolean bNewState= false;
object locker = new object();
public void SetNewState(Boolean State)
{
lock (locker)
{
bNewSate= State;
}
}
public Boolean ReadState()
{
lock (locker)
{
return bNewSate;
}
}
}
I have not understood this instruction:
What is the namespace for "Model" ?Code:Model m = new Model(); // All threads can access this model
Thanks,
That's not threadsafe.
Go read up on threading and thread safety and read a few tutorials (and do them too). It'll help.
I was demonstrating an example of how you control access to an object, not writing 100% functioning code. In 90%+ of cases you need to control access to the physical object, not controlling access to the getters and setters. Read my previous posts....
Yes, I fell I understand you now. You have solved slightly different task than me, maybe more complex. For clarification: if m.Value would be immutable, than my solution is completely thread-safe, is not it?
or you can simply declare the flag variable as volatile...
Code:public partial class Form1 : Form
{
privat volatile bool _flag = false;
private void ThreadProc() {
_flag = true; // set flag
}
private void SomeMethod() {
while (!_flag) {
// blah blah blah
}
}
}
by the way, what are you trying to accomplish here, if you don't mind? if you're just going to wait for a thread to finish you may use Join().
I used this concept to solve my purpose, Here I handled more than 100 threads
In Form side using InvokeRequired and Invoke I handled It is working fine. May be it will solve the multiple thread problemCode:///
private object locker = new object();
public delegate void EventTable(object sender, clsEventTableArgs e);
public event EventTable evtEventLog;
///
for(int l=0;l<100;l++)
{
Thread tt = new Thread(ThreadedMethod);
tt.Name = l.ToString();
tt.IsBackground = true;
tt.Start(l);
}
public void ThreadedMethod(object lTemp)
{
lock(locker)
{
DoStuff();
DoOperation(m.Value);
DoOtherOperation(m.Value);
DoMoreStuff();
Monitor.PulseAll(locker);
//Here I called raised the custom event to send this thred data to Form,I caught this data in form
clsEventTableArgs args = new clsEventTableArgs(m.Value, (int)lTemp);
evtEventLog(this, args);
}
}
If m.Value is completely immutable, then you don't need 'thead safety' as your object *cannot* change so it is by definition threadsafe.Quote:
Originally Posted by boudino
As for using the volatile keyword, it doesn't make things thread-safe. Thead safety is a hell of a lot more than just protecting access to variables and marking them as volatile.
I didn't think m.Value referene, but the object referenced/returned by m.Value. E.g. if m.Value would be value type rather than reference type. I'll try it explain by example:Quote:
Originally Posted by Mutant_Fruit
In my code, i is local and everything I want is to be sure that it has the value which the another thread could set.Code:Model<int> m = new Model<int>(); // model is implemented the way I've used before
...
m.Value = 20;
// start other thread which is using m and can modify it
// do other job in this thread
int i = m.Value;
Am I still wrong?
It could seem I'm obsedant with this, but I only want to fully understand I see my wrong to learn something new.
I wouldn't do this with an object or by locking on this as Mutant mentioned already.Quote:
Originally Posted by boudino
Here's one thread-safe way to do it.
The bottom line is providing thread safety to a shared variable is simply preventing more than one thread from accessing the variable while a write is occuring.Code:public class Model
{
private string _nameFirst = String.Empty;
private object _nameFirstLock = new object( );
public string NameFirst
{
get { lock (_nameFirstLock) return _nameFirst; }
set { lock (_nameFirstLock) _nameFirst = value; }
}
}
So when m.NameFirst is written to by one thread, and m.NameFirst is read from another thread, you need to only allow one thread access to the variable. This is what the lock statement does (internally it creates a critical section and enters and leaves during the scope of the lock statement).
I have been reviewing some tutorials, I am really a little confused (thanks for the links).
My program has a secondary thread consulting some peripheral (hardware) via comm1, when some event happens, it is created a new record in a SQL table. This thread must set a flag to indicate to a form that there are a new event in order to refresh a datagrid in such a way that the new record appears in screen.
Yes, technically this is perfectly threadsafe on all 32bit and higher platforms as writing a 32bit value is an atomic operation. But that does *not* require any locking to be 'thread safe'. The write is 1 operation and the read is 1 operation, therefore it is impossible to corrupt the value if you have multiple threads updating at the same time. So whether or not you add a 'lock' around it or mark it as volatile, you add no extra safety.Quote:
Originally Posted by boudino
As i've said several times already, arjay's method of 'thread safety' adds *no extra level of safety* to the code. It's useless. Let me illustrate with a concrete example:
As you can see, the getter and the setter are both protected by locks, so you think "Oh wow, this is threadsafe". It's not.Code:public class Model
{
private int _Number;
private object _nameFirstLock = new object( );
public int Number
{
get { lock (_nameFirstLock) return _Number; }
set { lock (_nameFirstLock) _Number = value; }
}
}
.....
void Method()
{
Model m = new Model();
m.Number ++;
}
In order to run the line, m.Number++, several operations are performed. In pseudo code:
int temp = m.Number;
temp = temp + 1;
m.Number = temp;
Suppose thread1 executes line 1 and line 2, then it gets interrupted by thread2. Thread2 then executes line 1, 2 then 3 and exits. Thread1 continues and puts what is now an invalid and *old* value of temp into number.
So assuming the initial value of m.Number was '0', the final value will be 1 as opposed to 2 despite the fact two threads ran and incremented the value. This is why that locking does not work.
This is a bit of a stupid example and i wouldn't be surprised if 'increment by 1' can be accomplished as a single atomic action. However the point is valid. That locking just doesn't work.
Actually what I displayed is thread safe with regard to protecting the get/set operations within the Property.
But as you know m.Number++; would call the get and then set so these two operations could be interupted.
These are points to think about though. If I need to increment/decrement I probably would do something like
acting on the varible directly and exposing threadsafe methods for class or external use.Code:int IncrementCounter( )
{
lock( _counterLock )
{
return _counter++;
}
}
int DecrementCounter( )
{
lock( _counterLock )
{
return _counter--;
}
}
Actually I wouldn't write it that way at all ( or use m.Number++ ); instead I would use the Interlocked methods.
Code:int IncrementCounter( )
{
return Interlocked.Increment( ref _counter );}
int DecrementCounter( )
{
return Interlocked.Decrement( ref _counter );
}
Yes, both of those would work. However they are just very specific workarounds for the very general problem i was outlining. My point is still there, proper access control to a classes variables can rarely (if ever) be effectively and efficiently controlled from entirely within that class.
You can't make everything threadsafe, so you need effective techniques to manage thread safety and thats what i'm trying to show.
I think it's a good idea to strive for thread safe encapsulation within a class and for the most part you can achieve it within the class. One exception however, would be when a class exposes an enumerator and you need to cycle through the enumerator items. Certainly some sort of external locking would be required in this case.
I believe an important goal is, whenever possible, attempt to contain the synchronization within the class so that users of the class need not concern themselves with the synchronization chores.
As an aside, I am working on a project that uses a dll to interact with a piece of hardware.
The following is an excerpt from the published documentation regarding the dll's thread safety:
"XYZ DLL is now also thread-safe. This means multi-threaded applications can call the API from different threads. Applications can pass channel handles between threads to allow multiple threads to access the same channel. However, it is the application’s responsibility to ensure more than one thread does not use the same channel at the same time. This can be done by using the Win32 synchronization functions to protect the channel handle."
I had to laugh when I read that because obviously the dll isn't thread safe if you need to provide external synchronization.
The above dll is a Win32 dll. The company also offer a .net version; however this one didn't fair much better. Creating a connection to the hardware, pinging it, and disconnecting causes it to leak memory, leak threads, and leak handles. Not real impressive.
yes generally volatile doesn't make things thread-safe but in this specific scenario there is no need to synchronize/lock access to the flag variable since it is going to be atomic. so i thought a volatile read/write is enough.Quote:
Originally Posted by Mutant_Fruit
I don't believe 'volatile' makes anything atomic. What volatile does is stop the compiler from making certain optimisations about reordering memory loads/writes. However a 'volatile' write to a long will still be two operations on a 32bit system (2x32bit writes). So that definitely isn't atomic.Quote:
Originally Posted by Thread1
I'm not 100% sure of this, but i can't find any docs which contradict that, and the stuff i've read only seems to mention the stuff about the memory reorderings.
Actually, you just alluded to a better solution.. Events..Quote:
Originally Posted by Marco Leon
Just provide an event on the code doing the reading, and make sure any subscribers to that event that are UI components, invoke on the UI thread
Thanks cjard for your suggestion, I will to learn about events.
Just be careful using events because you rarely have a guarantee that the event will fire on the main thead (unless you are the one writing the events or you can look at the source code to check). Therefore thread safety becomes an issue when using events.
Although you may use the event method to signal another thread to respond, it in itself doesn't guarantee a resource is protected so it's a good idea to update a shared resource with a lock, unlock and then fire the event. The event waiting thread would lock the resource, read it, and then unlock.
yes that is why the c# compiler will allow only certain types for volatile keyword (i.e. integral types/ native integer).Quote:
Originally Posted by Mutant_Fruit
or you can use the BackgroundWorker class. it can raise an event that runs on the context of the UI thread without the "Invoke/InvokeRequired".Quote:
Originally Posted by Marco Leon