Multithreading Synchronization Options 1

[fatcodeguy]

Hi, I'm trying to resolve some synchronization issues with a multithreaded application I have and I've run into several solutions, and i'm unsure what to do.

For startes, I have several threads that will access a single Queue. So I have the following:

SyncLock _resourceProcessQueue.SyncRoot
    _resourceProcessQueue.Enqueue(newResource)
End SyncLock

I think this works. Now what does the Queue.Synchronized(ByVal queue as Queue) method do? Should i do this as well? Or is it an alternative solution?

Private _resourceProcessQueue As Queue = Queue.Synchronized(New Queue)

Finally, there's also the use of the Mutex object, which allows you to create a critical section managed by the object. Is there an advantage to using this altertative instead of the one(s) mentioned above?

Thanks for all the help!!

 

[ThatRickGuy]

Using SyncLock reserves a memory address. Here is a sample of how I use it with my Logging system

Class LogManager
  private shared m_ThreadLock() as integer

  Public Shared Sub LogItem(Message as string, LogCode as LogCodeEnumeration)
    SyncLock m_ThreadLock

      'My Logging Code

    End SyncLock
  End Sub

When the thread calls LogItem, it hits the SyncLock on the m_ThreadLock object (an empty array, which I beleive is comprised of a single memory address on the stack with no value). At that point, the thread tries to claim "dibs" on that memory address. If some other thread has "dibs" on that memory address, this thread waits until it is free. Onces the memory address frees up, this thread claims dibs and all other threads trying to call LogItem have to wait for it to be released.

As for Mutex and The Queue object, I'm not sure, I haven't had to play with them much so far, but RG and Chip might know more about them.

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.

 

[chiph]

Synclocks only work in your AppDomain. A Mutex is a wrapper for a Win32 mutex, and so works across the entire computer.

You should use the minimal level of locks that you need to accomplish your goal simply because synchronization is intrusive. Worst case, if your locks aren't implemented correctly (A needs something that B is holding, and B needs something that A is holding), you can end up in a deadlock.

If you're only running in the default AppDomain, and only need to protect shared resources in your application, then a synclock is the way to go.

If you need to protect shared resources that cross AppDomains, or are shared amongst multiple processes on the same computer, then a Mutex is what you'd use.

Chip H.


____________________________________________________________________
Donate to Katrina relief:

http://s1.amazon.com/paypage/PELYGQVJ8Q7IB/103-6821258-5919825

If you want to get the best response to a question, please read FAQ222-2244 first

 

[ThatRickGuy]

Good to know Chip!

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.

 

[chrissie1]

So when married use Mutex.

Christiaan Baes
Belgium

I just like this --> [Wiggle] [Wiggle]