472,099 Members | 2,220 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,099 software developers and data experts.

Thread synchronization

hi all,

Thx to any one that can offer me help, it will be much appreciated.

iv got a multithreaded program and need to use thread synchronization. The
synchronization does not have to work across multiple processes just the
one. I was wondering if any one new which one used the least overhead. Im
at current using mutexes but was wondering if there was something a bit
faster.

Iv looked at the Interlocked class and that seemed to do almost everything i
wanted but one thing. From looking at sample code it did not seem to go
into a wait state.

Thx for any help

Scott.
Nov 17 '05 #1
4 3024
If you need synchronization solely for the purpose of incrementing,
decrementing, comparing, and/or exchanging values then the Interlocked
routines are probably what you want. I'm not sure what you mean by them "not
going into a wait state" -- they guarantee atomic operation so if two threads
try to perform an interlocked operation on the same variable concurrently,
one of them must block until the other finishes its interlocked operation!

Otherwise the lock(object o) {...} construct (based on the Monitor class)
seems pretty good. Just out of curiosity, what do you mean by "something a
bit faster" than mutexes? Have you determined that the Mutex class is a
bottleneck in your application? What latency are you seeing between one
thread releasing a Mutex and a blocked thread coming out its wait on the
Mutex? What is the cost of calling WaitOne on an unowned Mutex?

I guess I would be a little surprised if the Mutex operations were really so
heavyweight that you would notice.

-- Tom

"scott" wrote:
iv got a multithreaded program and need to use thread synchronization. The
synchronization does not have to work across multiple processes just the
one. I was wondering if any one new which one used the least overhead. Im
at current using mutexes but was wondering if there was something a bit
faster.

Iv looked at the Interlocked class and that seemed to do almost everything i
wanted but one thing. From looking at sample code it did not seem to go
into a wait state.


Nov 17 '05 #2
Thx for the reply.

sounds like mutexes might be the best ones to use then. My only worry was
that i have one thread that goes through a continues loop of up to may be
3000 or more (sleeping for 100 every time the loop is complete then starting
the loop again). Within that loop i need to use synchronization about 20
times. I just wanted to use the fastest possible way of synchronization
between 2 threads.

"Thomas W. Brown" <th************@countrywide.NOSPAM.com> wrote in message
news:D2**********************************@microsof t.com...
If you need synchronization solely for the purpose of incrementing,
decrementing, comparing, and/or exchanging values then the Interlocked
routines are probably what you want. I'm not sure what you mean by them "not going into a wait state" -- they guarantee atomic operation so if two threads try to perform an interlocked operation on the same variable concurrently,
one of them must block until the other finishes its interlocked operation!

Otherwise the lock(object o) {...} construct (based on the Monitor class)
seems pretty good. Just out of curiosity, what do you mean by "something a bit faster" than mutexes? Have you determined that the Mutex class is a
bottleneck in your application? What latency are you seeing between one
thread releasing a Mutex and a blocked thread coming out its wait on the
Mutex? What is the cost of calling WaitOne on an unowned Mutex?

I guess I would be a little surprised if the Mutex operations were really so heavyweight that you would notice.

-- Tom

"scott" wrote:
iv got a multithreaded program and need to use thread synchronization. The synchronization does not have to work across multiple processes just the
one. I was wondering if any one new which one used the least overhead. Im at current using mutexes but was wondering if there was something a bit
faster.

Iv looked at the Interlocked class and that seemed to do almost everything i wanted but one thing. From looking at sample code it did not seem to go
into a wait state.

Nov 17 '05 #3
Scott:

If you are worried about the weight, you might seriously consider using the
Monitor class instead of a Mutex. The Monitor is the same object that is
used intrinsically with a Lock() statement.

The Monitor is a light-weight synchronization object (lighter than a Mutex).
It is only visible in-process, but I believe that you stated that you do not
need for it to work cross-process anyway.

"scott" <sc***********@hotmail.com> wrote in message
news:d8**********@newsg3.svr.pol.co.uk...
Thx for the reply.

sounds like mutexes might be the best ones to use then. My only worry was
that i have one thread that goes through a continues loop of up to may be
3000 or more (sleeping for 100 every time the loop is complete then
starting
the loop again). Within that loop i need to use synchronization about 20
times. I just wanted to use the fastest possible way of synchronization
between 2 threads.

"Thomas W. Brown" <th************@countrywide.NOSPAM.com> wrote in message
news:D2**********************************@microsof t.com...
If you need synchronization solely for the purpose of incrementing,
decrementing, comparing, and/or exchanging values then the Interlocked
routines are probably what you want. I'm not sure what you mean by them

"not
going into a wait state" -- they guarantee atomic operation so if two

threads
try to perform an interlocked operation on the same variable
concurrently,
one of them must block until the other finishes its interlocked
operation!

Otherwise the lock(object o) {...} construct (based on the Monitor class)
seems pretty good. Just out of curiosity, what do you mean by "something

a
bit faster" than mutexes? Have you determined that the Mutex class is a
bottleneck in your application? What latency are you seeing between one
thread releasing a Mutex and a blocked thread coming out its wait on the
Mutex? What is the cost of calling WaitOne on an unowned Mutex?

I guess I would be a little surprised if the Mutex operations were really

so
heavyweight that you would notice.

-- Tom

"scott" wrote:
> iv got a multithreaded program and need to use thread synchronization. The > synchronization does not have to work across multiple processes just
> the
> one. I was wondering if any one new which one used the least overhead. Im > at current using mutexes but was wondering if there was something a bit
> faster.
>
> Iv looked at the Interlocked class and that seemed to do almost everything i > wanted but one thing. From looking at sample code it did not seem to
> go
> into a wait state.


Nov 17 '05 #4
scott <sc***********@hotmail.com> wrote:
iv got a multithreaded program and need to use thread synchronization. The
synchronization does not have to work across multiple processes just the
one. I was wondering if any one new which one used the least overhead. Im
at current using mutexes but was wondering if there was something a bit
faster.

Iv looked at the Interlocked class and that seemed to do almost everything i
wanted but one thing. From looking at sample code it did not seem to go
into a wait state.


Monitors are almost certainly the way to go. I suggest you read
http://www.pobox.com/~skeet/csharp/threads

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

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Robert Speck | last post: by
13 posts views Thread by arun.darra | last post: by
8 posts views Thread by Brad Walton | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.