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

locking question

P: n/a
Hi,

I have a MDIChild with static properties that can be updated at any time
by the MDIParent. These
properties may also at unknown times be accessed by one or more worker
threads.

Now, I'm not too familiar with threads, but is there a danger that these
properties can get corrupted? MDIParent will only SET the properties while
the worker threads will only GET them. If so how do you lock them and to
what?

Morten
Nov 16 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
If you don't use any kind of syncronization, there's a possibility that the
worker threads will read the properties before they've been updated.
Generally speaking, when two or more threads need access to a resource,
access to that resource should be syncronized. All you need to do is lock
on a syncronization object in the get/set of your MDIChild class.
Something like this (note that I used static becasue you mentioned in your
post that your properties are static):

// sync object defined in MDIChild class
private static object syncObject = new object();
...
// the static property of the MDIChild class
private static int theInt = 0;
...
// the static property accessors of MDIChild
public static int MyIntProperty
{
get
{
lock (syncObject)
{
return theInt;
}
}
set
{
lock (syncObject)
{
theInt = value;
}
}
}

Check out this link for more info on multithreaded design:
http://msdn.microsoft.com/library/de...us/dv_vstechar
t/html/vbtchasyncprocvb.asp

hth

-Joel
--------------------
Subject: locking question
From: Morten Wennevik <Mo************@hotmail.com>
Content-Type: text/plain; format=flowed; charset=iso-8859-15
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Date: Mon, 19 Apr 2004 22:38:20 +0200
Message-ID: <opr6p0x6fxhntkfz@localhost>
User-Agent: Opera7.23/Win32 M2 build 3227
Newsgroups: microsoft.public.dotnet.languages.csharp
NNTP-Posting-Host: h192n1fls32o817.telia.com 213.67.67.192
Lines: 1
Path: cpmsftngxa10.phx.gbl!TK2MSFTFEED01.phx.gbl!TK2MSFT NGP08.phx.gbl!TK2MSFTNGP12
..phx.gblXref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.languages.csharp:238300
X-Tomcat-NG: microsoft.public.dotnet.languages.csharp

Hi,

I have a MDIChild with static properties that can be updated at any time
by the MDIParent. These
properties may also at unknown times be accessed by one or more worker
threads.

Now, I'm not too familiar with threads, but is there a danger that these
properties can get corrupted? MDIParent will only SET the properties while
the worker threads will only GET them. If so how do you lock them and to
what?

Morten

--------------------------------------------------------------------
This reply is provided AS IS, without warranty (express or implied).
Nov 16 '05 #2

P: n/a
Ah,

Thank you, I knew of the possibility of access violations, but the lock
required some object.
Since the properties are static I couldn't use 'this'. So, any object
will do?

Happy coding!
Morten Wennevik [C# MVP]
Nov 16 '05 #3

P: n/a
Morten Wennevik <Mo************@hotmail.com> wrote:
Thank you, I knew of the possibility of access violations, but the lock
required some object.
Since the properties are static I couldn't use 'this'. So, any object
will do?


Yes, but preferably (IMO) one which no other classes have access to. I
usually have a separate variable which contains a reference to an
object which is *solely* used for locking. I may have several in a
class, depending on the locking granularity required.

I'm writing a sort of introduction and tips page on multithreading -
I'll post when I'm done with it. (It may be some time though - it's a
nasty subject!)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.