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

Using Classes with threads

P: n/a
Can someone please discuss "Synclock" or other methods to use for making a
class 'thread safe". I need to have about 4 processes running (probably on
backgroundworker threads) and all will need to call the same class for
reading data (not SQL Server). If each worker thread creates an "instance"
of the class, won't that be good enough?
TIA
Jul 15 '07 #1
Share this Question
Share on Google+
4 Replies


P: n/a
=?Utf-8?B?bG91aXM=?= <lo***@discussions.microsoft.comwrote in
news:D1**********************************@microsof t.com:
Can someone please discuss "Synclock" or other methods to use for
making a class 'thread safe". I need to have about 4 processes
running (probably on backgroundworker threads) and all will need to
call the same class for reading data (not SQL Server). If each worker
thread creates an "instance" of the class, won't that be good enough?
Yes, if each thread has their own instance of data then you do not need to
synchronize access to the object. Synclock is used when you need to
synchronize cross thread access. In essence Synclock single threads access
to a particular object to prevent multiple threads from accessing and
changing and object at a particular time.

Do these processes have any functions that can be called from another
thread? If they do - then you'll need to synclock :-)
Jul 15 '07 #2

P: n/a
the class has several public vars that are set/read. It has also has
initialize and terminate events (currently in VB6). It has 1 main public
function that could be called by any of the 4 processes at any time. An
article I found on MSDN leads me to believe I should use Synclock to prevent
2 or more process from using (changing vars) in the class at the same time.

"Spam Catcher" wrote:
=?Utf-8?B?bG91aXM=?= <lo***@discussions.microsoft.comwrote in
news:D1**********************************@microsof t.com:
Can someone please discuss "Synclock" or other methods to use for
making a class 'thread safe". I need to have about 4 processes
running (probably on backgroundworker threads) and all will need to
call the same class for reading data (not SQL Server). If each worker
thread creates an "instance" of the class, won't that be good enough?

Yes, if each thread has their own instance of data then you do not need to
synchronize access to the object. Synclock is used when you need to
synchronize cross thread access. In essence Synclock single threads access
to a particular object to prevent multiple threads from accessing and
changing and object at a particular time.

Do these processes have any functions that can be called from another
thread? If they do - then you'll need to synclock :-)
Jul 15 '07 #3

P: n/a
=?Utf-8?B?bG91aXM=?= <lo***@discussions.microsoft.comwrote in
news:04**********************************@microsof t.com:
the class has several public vars that are set/read. It has also has
initialize and terminate events (currently in VB6). It has 1 main
public function that could be called by any of the 4 processes at any
time. An article I found on MSDN leads me to believe I should use
Synclock to prevent 2 or more process from using (changing vars) in
the class at the same time.
Yes. However, synclocking is not that cut and dry ... you'll need to get
more familiar with threading and then apply synclocking in places where it
makes sense.
Jul 15 '07 #4

P: n/a
louis wrote:
Can someone please discuss "Synclock" or other methods to use for making a
class 'thread safe". I need to have about 4 processes running (probably on
backgroundworker threads) and all will need to call the same class for
reading data (not SQL Server).
Synclock is a keyword that provides simple access to the Monitor class.
Monitor allows you to ensure that only one Thread is running a given
piev of code at any given time.
If each worker thread creates an "instance" of the class,
won't that be good enough?
Strictly speaking, no.
You ought to have synchronisation logic on "sensitive" methods so that
only one Thread can be executing it at any time. Without this, you can
get updates interlacing with one another, causing a hell of mess.

However, since you are "wrapping up" a /database/ it may not be so much
of an issue; you could probably manage the synchronisation just as
easily at the database level.
HTH,
Phill W.
Jul 17 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.