By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,422 Members | 1,263 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,422 IT Pros & Developers. It's quick & easy.

Thread-safe methods...

P: n/a
Hello! I'm working on an asynchronous network application that uses
multiple threads to do it's work. I have a ChatClient class that
handles the basic functionality of connecting to a server and sending/
receiving messages. The problem is, some of the ChatClient methods
access another ChatWindow class that is derived from a Form and that
causes some methods in ChatClient to required an Invoke().

My question is: is it possible to make thread-safe methods within a
class that isn't derived from a Windows Form?

I would like the ChatClient class to be reusable and I was wondering
if there is any way to make the methods thread-safe so the front-end
doesn't need to worry about Invoke'ing. Thanks in advance.

Feb 23 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a
On Feb 22, 9:44 pm, "tcomer" <tco...@gmail.comwrote:
Hello! I'm working on an asynchronous network application that uses
multiple threads to do it's work. I have a ChatClient class that
handles the basic functionality of connecting to a server and sending/
receiving messages. The problem is, some of the ChatClient methods
access another ChatWindow class that is derived from a Form and that
causes some methods in ChatClient to required an Invoke().

My question is: is it possible to make thread-safe methods within a
class that isn't derived from a Windows Form?

I would like the ChatClient class to be reusable and I was wondering
if there is any way to make the methods thread-safe so the front-end
doesn't need to worry about Invoke'ing. Thanks in advance.
Hi,
Yes it's possible to make a thread-safe method in a class that isn't a
Windows Form. Inside your method that is called from a non-UI thread,
you can simply do

void MyMethod() {
if (this.InvokeRequired) {

this.Invoke ((MethodInvoker)(new delegate()
{ DoSomething(); } ));
}
else {
DoSomething();
}
}

// The InvokeRequired property simply checks that the calling thread
the thread that owns the UI object. If they don't equal, then an
invoke is required.

If you want to make your non-UI class methods thread safe, there are a
number of ways. You can lock an object while you perform some
operation

private object myLock = new object();

void DoSomething() {

lock (myLock) {

// Perform some thread-safe operations here.
}
}

You can use the c# volatile keyword to make members in your class
thread-safe (watch out on reference types though, they are not
guaranteed to be thread-safe using volatile).

Hope this helps,

Feb 23 '07 #2

P: n/a
tcomer wrote:
I would like the ChatClient class to be reusable and I was wondering
if there is any way to make the methods thread-safe so the front-end
doesn't need to worry about Invoke'ing. Thanks in advance.
I'm not sure what your architecture is, but when I need a class to call
methods that may need to be on a UI thread, I make sure that the class
instance has a reference to an implementation of ISynchronizeInvoke.

Form, Control etc. and other UI components implement ISynchronizeInvoke.

Methods that need to do work can then implement the Invoke manually.

If you want more details, I think you'll have to explain what your
architecture in more detail, because it's not clear exactly what your
classes are, what responsibilities they have, and what threads their
methods execute on, and what you mean by "front end". (By front end, I
usually think "UI" - but UI calls are already on the UI thread, so why
would it worry about Invoke?)

I'd recommend designing your classes so their public interfaces have an
explicit, documented thread context in mind. "Automatic" thread safety
can easily lead to deadlocks or worse if you're not careful.
Synchronization is part of the API, and if callers don't know in a fair
amount of details exactly what synchronization is being done behind the
scenes, you'll find it easy to get into trouble.

-- Barry

--
http://barrkel.blogspot.com/
Feb 23 '07 #3

P: n/a
I'd recommend designing your classes so their public interfaces have an
explicit, documented thread context in mind. "Automatic" thread safety
can easily lead to deadlocks or worse if you're not careful.
Synchronization is part of the API, and if callers don't know in a fair
amount of details exactly what synchronization is being done behind the
scenes, you'll find it easy to get into trouble.
That's what I was wondering, basically if it would good design to
implement thread-safe methods in my non-UI class. You guys have
answered my question. I've hit the point where I'm more concerned with
design than actual coding and I wasn't sure how to handle this. Thanks
to both of you for your help
Feb 23 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.