Re: Thread synchronization

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" <thomas_w_brown@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:D284C5EC-8266-43DD-BAA9-94FF7CAAFB85@xxxxxxxxxxxxxxxx
> 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.
>


.

Relevant Pages

  • Re: WaitForSingleObject() will not deadlock
    ... And in what way am I wrong about Windows mutexes? ... expectations would violate the *documented* mutex behavior). ... building only experimental systems (my first synchronization system was ...
    (microsoft.public.vc.mfc)
  • RE: Thread synchronization
    ... try to perform an interlocked operation on the same variable concurrently, ... thread releasing a Mutex and a blocked thread coming out its wait on the ... > iv got a multithreaded program and need to use thread synchronization. ... > at current using mutexes but was wondering if there was something a bit ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: msleep() on recursivly locked mutexes
    ... Further the idea that holding a mutex "except for when we sleep" is a ... This is basically when I need to exit mutexes. ... I agree with the other comment that all drivers should be multi-thread ... lock a mutex again. ...
    (freebsd-hackers)
  • Re: msleep() on recursivly locked mutexes
    ... Further the idea that holding a mutex "except for when we sleep" is a ... release it during sleep you probably should invalidate all assumptions ... This is basically when I need to exit mutexes. ... it is not always possible to drop the blocking lock ...
    (freebsd-hackers)
  • Re: Obscure mutex problem
    ... PTHREAD_MUTEX_RECURSIVE to make the mutexes work at all... ... mutex fine, and then thread B would attempt to lock it, but instead ... That pre-NPTL-Linux does not support 'real' multithreading 'but some ...
    (comp.os.linux.development.apps)