Thread safety

I made this client/server application, in which the server uses a thread to listen for clients. All the listening is done within a single-instance class, and all communication to the primary thread is done through events. This all works fine in VB2003, but when exported to VB2010 the events (client message received, connection established etc.) trigger a thread safety exception, due to manipulation of objects outside thread.
The solution to use out-of-thread properties apparently is to use an asynchronous callback or use a background worker and it's completion event.
Neither of these solutions are really appealing, since they both will require a substantial amount of additional coding and the background worker especially isn't feasible (thread supposed to keep running). The programming ought to be thread-safe as is in my opinion, since one thread is raising events only (no manipulation of objects) and the other thread listens for events and reacts to them through function parameters.

1) Is there any way around this problem (using VB2010 that is :))?
2) Is my code thread safe as is, or am I missing something?
3) Which of the 2 approaches (background worker or asynchronous callbacks) should I choose, if I decide to make the server thread safe.

Thanks for any inputs
Tom

1) There's always a way around it, that typically involves recoding.
2) I would tell you, but I can't see any code to tell you.
3) I would use delegation actually, but my TCPV2 class is all object based, no GUI interactions. You can pull examples from that (link is in my signature), and you can even do a search for JMC's Asynchronous class in the codebank as well.

Quote:

---

Originally Posted by formlesstree4

1) There's always a way around it, that typically involves recoding.
2) I would tell you, but I can't see any code to tell you.
3) I would use delegation actually, but my TCPV2 class is all object based, no GUI interactions. You can pull examples from that (link is in my signature), and you can even do a search for JMC's Asynchronous class in the codebank as well.

---

Will try to have a look at that. Thank you for the help :wave:
Oh and it was quite deliberate, that I didn't included code, since it isn't something you just browse through in 5 mins.

Tom

There are fixes and hacks... Fixes involve rewriting your code in a thread-safe manner by using delegates, backgroundworkers.. as you already mentioned. Hacks mean using an approach that yield the least code changes yet still allow get away with the issue. Nobody recommend hacks, but sometimes, for some reason such as time constraint, you need to get away with an issue as quick as possible. And in this case, if you want the hacking approach, you simply set the controls's CheckForIllegalCrossThread property to False.

Quote:

---

Originally Posted by ThomasJohnsen

Will try to have a look at that. Thank you for the help :wave:
Oh and it was quite deliberate, that I didn't included code, since it isn't something you just browse through in 5 mins.

Tom

---

Ah I gotcha. And as stanav said, you can set the CheckForIllegalCrossThread Property to False on controls. That's definitely a hack that I'm not fond of as it feels like I'm cheating the system.

Quote:

---

Originally Posted by stanav

There are fixes and hacks... Fixes involve rewriting your code in a thread-safe manner by using delegates, backgroundworkers.. as you already mentioned. Hacks mean using an approach that yield the least code changes yet still allow get away with the issue. Nobody recommend hacks, but sometimes, for some reason such as time constraint, you need to get away with an issue as quick as possible. And in this case, if you want the hacking approach, you simply set the controls's CheckForIllegalCrossThread property to False.

---

I'd like to solve this is a non-hack based manner :)
But thank you very much for the input - might be a temporary solution.

I'd still like to know though: is it possible for a thread that only raises events to cause another thread responding to these events and not interfering in any other way with the other thread (function arguments are byval), to be non-thread-safe? Even with all the university teachings (granted it was a long time ago), I can't wrap my head around how that would ever cause a conflict.

Tom

Quote:

---

I'd still like to know though: is it possible for a thread that only raises events to cause another thread responding to these events and not interfering in any other way with the other thread (function arguments are byval), to be non-thread-safe? Even with all the university teachings (granted it was a long time ago), I can't wrap my head around how that would ever cause a conflict.

---

Its not the threads interacting with each other specifically that causes the problems, its the threads both interacting with the same objects. If you had a List(Of String) for example that both threads could access, if one thread was looping through that list whilst the other thread was removing items from that list then it will cause problems because the thread that is looping through the list will suddenly find that the list is not in the state that it was expecting it to be in (this usually generates an exception stating that "the collection has been modified").

Also an important point to note - passing arguments ByVal does not make any difference if the object you are passing is a Reference type (a Class). When you pass a reference type ByVal it just passes a copy of the reference, rather than a copy of the actual object, so the method accepting the argument does not get its own copy of whatever object you passed in, it just gets a reference to the same object that the calling method was using. This is especially important to understand in a multi-threaded application.


You say you are getting a cross thread exception - can you show us the code where you actually get this exception and explain which thread is executing that code etc, and then we can probably give you more specific advice.

Quote:

---

The programming ought to be thread-safe as is in my opinion, since one thread is raising events only (no manipulation of objects) and the other thread listens for events and reacts to them through function parameters

---

I dont quite understand this sentence, how can one thread just be raising events without manipulating any objects - how does it know when to raise an event and where does it get the values from that it passes in as arguments?