Thread safety

[TimK]

Thanks for these comments. From the comments made earlier I was starting to think that my understanding of the need for synchronization was completely wrong. Your comments have really cleared things up for me. :)

[Meysam Mahfouzi]

Hummmm, but because of one reason, you may need to use lock in your first example. Consider below situation: A thread(say thread_A) reaches here:

if (Event != null){
Event(this, e);
}

thread_A checks and sees that Event is not null, and goes to fire Event(this, e). But before calling it, its time slice terminates. Now suppose that in our main application, by using **-=** operator the Event gets null. Now it's thread_A's turn to continue. But an exception will be fired by calling Event(this, e). This will not happen be using below code:

lock(this){
if (Event != null){
Event(this, e);
}
}

I am wondered why below code doesn't lock the Event and the exception would occur:

lock(Event){
if (Event != null){
Event(this, e);
}
}

---

Don't forget, that's

Persian Gulf

not Arabian gulf!

[TimK]

Your example is interesting but I think that your suggested solution is flawed. Placing the lock around the event raising code e.g.

lock(this) {
if (Event != null) {
Event(this, e);
}
}

will not stop our main application from using -= operator on the Event. The lock places the event raising code in a critical section. It does not stop other threads accessing the Event property. What do you think?:confused:

[Meysam Mahfouzi]

I don't think;), I tried it and it worked seamlessly!:)

---

Don't forget, that's

Persian Gulf

not Arabian gulf!

[TimK]

OK ... How about posting your test code.

[scadaguy]

I mentioned this problem briefly in my original post. My example code assumes that all event handlers have been added prior to calling ThreadTest.Start(). It's easy is see that unsubscribing with -= will cause a lot of problems after the threads have been started, but += could be problematic as well. This problem is difficult solve correctly and that is why I suggested to intentionally leave the ThreadTest class unsafe for multithreading. Simply locking the code that raises the event is insufficient. You must lock the -= and += operators as well. This can be done with special syntax, using the add and remove keywords.

public class ThreadTest
{
private ArrayList _events = new ArrayList();

public event EventHandler MyEvent
{
add { lock (this) { _events.Add(value); } }
remove { lock (this) { _events.Remove(value); } }
}

public void Start()
{
// Same code as before
}

private void ThreadMethod()
{
while (true)
{
ArrayList clone;
lock (this)
{
clone = (ArrayList)_events.Clone();
}
foreach (EventHandler e in clone)
{
e.DynamicInvoke(...);
}
}
}
}

If you're going to do this you might as well make every method on ThreadTest thread-safe to avoid confusion and inconsistency. This solution still requires that subscribers handle their on synchronization. Brian

[scadaguy]

You were lucky :)

[scadaguy]

TimK wrote: What do you think? You are correct.

[Meysam Mahfouzi]

I just need your e-mail to send source code for you.

---

Don't forget, that's

Persian Gulf

not Arabian gulf!

[Meysam Mahfouzi]

Brian Gideon wrote: You were lucky I can post the source code for you and you will see you are more lucky than me after running it and having no exception! ;);P (need for your mail)

---

Don't forget, that's

Persian Gulf

not Arabian gulf!