I have a question regarding synchronization across multiple threads for a
Hashtable. Currently I have a Threadpool that is creating worker threads
based on requests to read/write to a hashtable. One function of the
Hashtable is to iterate through its keys, which apparently is inherently not
thread-safe. Other functions of the Hashtable include
adding/modifying/deleting.
To solve the synchronization issues I am doing two things:
1. Lock the syncroot of the Hashtable for any "write" operations:
Lock(myHashTabl e.Syncroot)
{ do some writing/deleting }
2. Wrap the Hashtable in a synchronized Hashtable for any iterations:
Hashtable mySynchedTable = Hashtable.Synch ronized(myHashT able);
foreach(key in mySynchedTable)
{ .. do some reading }
My question is: is this enough? Is there anything missing, or should this be
enough to ensure synchronization across multiple threads accessing my
Hashtable.
Thanks! 5 15583
lock it yourself in all read or write methods using
lock(syncRoot)
{
foreach(...)
update/etc.
}
The problem with sync wrapper is it is locked every access so if you have a
method that does iteration and updates and counts, etc you keep locking it
multiple times. Also, something you need exclusive lock for a set of
operations that need to be in the same lock context to be safe. You could
still use the syncwrapper, but you end up locking twice. It is a bit more
work, but I would set your locks yourself unless your needs are simple.
--
William Stacey, MVP http://mvp.support.microsoft.com
"Cyrus" <Cy***@discussi ons.microsoft.c om> wrote in message
news:71******** *************** ***********@mic rosoft.com... I have a question regarding synchronization across multiple threads for a Hashtable. Currently I have a Threadpool that is creating worker threads based on requests to read/write to a hashtable. One function of the Hashtable is to iterate through its keys, which apparently is inherently
not thread-safe. Other functions of the Hashtable include adding/modifying/deleting.
To solve the synchronization issues I am doing two things: 1. Lock the syncroot of the Hashtable for any "write" operations: Lock(myHashTabl e.Syncroot) { do some writing/deleting }
2. Wrap the Hashtable in a synchronized Hashtable for any iterations: Hashtable mySynchedTable = Hashtable.Synch ronized(myHashT able); foreach(key in mySynchedTable) { .. do some reading }
My question is: is this enough? Is there anything missing, or should this
be enough to ensure synchronization across multiple threads accessing my Hashtable.
Thanks!
Thanks for the reply. Currently I have it set up to do: lock(myHash.syn cRoot)
around any write methods and use a Hashtable.Synch ronized wrapper around any
of my iterations like:
Hashtable mySynch = Hashtable.Synch ronized(myHash) ;
foreach (string Key in mySynch.Keys)
{
MyObject tempObject = (MyObject)mySyn ch[Key];
tempObject.doSo meWork();
}
So from your post, I gather that this Synchronized Wrapper is doing a lock
each iteration of the Hashtable? So I'd be better off doing:
lock(myHash.syn cRoot)
{
foreach (string Key in myHash.Keys)
{
MyObject tempObject = (MyObject)myHas h[Key];
tempObject.doSo meWork();
}
}
so this would lock only once?
Thanks!
"William Stacey [MVP]" wrote: lock it yourself in all read or write methods using lock(syncRoot) { foreach(...) update/etc. }
The problem with sync wrapper is it is locked every access so if you have a method that does iteration and updates and counts, etc you keep locking it multiple times. Also, something you need exclusive lock for a set of operations that need to be in the same lock context to be safe. You could still use the syncwrapper, but you end up locking twice. It is a bit more work, but I would set your locks yourself unless your needs are simple.
-- William Stacey, MVP http://mvp.support.microsoft.com
"Cyrus" <Cy***@discussi ons.microsoft.c om> wrote in message news:71******** *************** ***********@mic rosoft.com... I have a question regarding synchronization across multiple threads for a Hashtable. Currently I have a Threadpool that is creating worker threads based on requests to read/write to a hashtable. One function of the Hashtable is to iterate through its keys, which apparently is inherently not thread-safe. Other functions of the Hashtable include adding/modifying/deleting.
To solve the synchronization issues I am doing two things: 1. Lock the syncroot of the Hashtable for any "write" operations: Lock(myHashTabl e.Syncroot) { do some writing/deleting }
2. Wrap the Hashtable in a synchronized Hashtable for any iterations: Hashtable mySynchedTable = Hashtable.Synch ronized(myHashT able); foreach(key in mySynchedTable) { .. do some reading }
My question is: is this enough? Is there anything missing, or should this be enough to ensure synchronization across multiple threads accessing my Hashtable.
Thanks!
> So from your post, I gather that this Synchronized Wrapper is doing a lock each iteration of the Hashtable?
Not 100% on that. Each method or property access is wrapped in a lock,
hence the name.
So I'd be better off doing: lock(myHash.syn cRoot) { foreach (string Key in myHash.Keys) { MyObject tempObject = (MyObject)myHas h[Key]; tempObject.doSo meWork(); } }
That is much better then first example. Also, from first example, you would
creating a new wrapper for every access - but can not tell for sure without
the whole class or a small class sample. Normally you end up needing a
lock{} to handle a few atomic operations regarding table and/or other stuff.
So having to handle both the wrapper and manual locks get a bit messy IMO
and have the two lock overhead if using both. For that reason I find easier
to reason about the locking on shared resources if I just do the locks
myself and I think makes your code more understandable as it is explicit
what your doing. But others may disagree. Cheers.
--
William Stacey, MVP http://mvp.support.microsoft.com
Thanks! I'll give it a shot!
"William Stacey [MVP]" wrote: So from your post, I gather that this Synchronized Wrapper is doing a lock each iteration of the Hashtable? Not 100% on that. Each method or property access is wrapped in a lock, hence the name.
So I'd be better off doing: lock(myHash.syn cRoot) { foreach (string Key in myHash.Keys) { MyObject tempObject = (MyObject)myHas h[Key]; tempObject.doSo meWork(); } }
That is much better then first example. Also, from first example, you would creating a new wrapper for every access - but can not tell for sure without the whole class or a small class sample. Normally you end up needing a lock{} to handle a few atomic operations regarding table and/or other stuff. So having to handle both the wrapper and manual locks get a bit messy IMO and have the two lock overhead if using both. For that reason I find easier to reason about the locking on shared resources if I just do the locks myself and I think makes your code more understandable as it is explicit what your doing. But others may disagree. Cheers.
-- William Stacey, MVP http://mvp.support.microsoft.com
Actually in .NET 1.1. the synchronized hashtable only actually locks on
removes if I recall correctly.
Some interesting info for people using hashtables:
1. When threading use the synchronized hastable wrapper if you are not
worried about not seeing writes immediately when done from another thread.
2. The synchronized hashtable only locks on deletions internally as it
copies buckets normal to avoid locking
3. Given the above implementation it is slow, but provides good parallelism
and reduced contention
4. Given #1 is ok for you, you only need to lock if you need to enumerate
all of the elements in the hashtable since the enmerator is not thread safe.
5. For even higher performance given a well known dataset and using strings
as keys you might try a different hash algorithm, the MS one is nicely
distributed producing few collisions but is slow compared to other algorithms
that would produce more collisions for large data sets, but if your data set
is well known or small and diverse some more simplistic algorithms may work
for you.
"Cyrus" wrote: Thanks! I'll give it a shot!
"William Stacey [MVP]" wrote:
So from your post, I gather that this Synchronized Wrapper is doing a lock each iteration of the Hashtable? Not 100% on that. Each method or property access is wrapped in a lock, hence the name.
So I'd be better off doing: lock(myHash.syn cRoot) { foreach (string Key in myHash.Keys) { MyObject tempObject = (MyObject)myHas h[Key]; tempObject.doSo meWork(); } }
That is much better then first example. Also, from first example, you would creating a new wrapper for every access - but can not tell for sure without the whole class or a small class sample. Normally you end up needing a lock{} to handle a few atomic operations regarding table and/or other stuff. So having to handle both the wrapper and manual locks get a bit messy IMO and have the two lock overhead if using both. For that reason I find easier to reason about the locking on shared resources if I just do the locks myself and I think makes your code more understandable as it is explicit what your doing. But others may disagree. Cheers.
-- William Stacey, MVP http://mvp.support.microsoft.com
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics |
by: Philip V Pham |
last post by:
These questions apply to std vector, map, and cout:
I am uncertain of the thread safety for reading/writing
for std templates. I know if all threads are reading
concurrently, it is thread safe. However, I have this situation:
Case 1: map
thread 1
---------
|
by: Anders Borum |
last post by:
Hello!
I'm am currently working on making a central cache component threadsafe, and
was looking at the synchronized implementation of the Hashtable. I was
wondering why you'd really want to enforce thread safety in a remove method?
Why would you care if two threads are trying to remove the same key from the
hashtable? In the end, the key is removed (and that was probably what you
were looking for).
|
by: GroZZleR |
last post by:
Hey all,
I'm threading newbie, I've never attempted it before. I've got a
button that when clicked starts up a thread to process some files.
This keeps my GUI responsive and gets the tasks done.
Here's an example of what I'm doing:
====================================
private void button1_Click(object sender, System.EventArgs e)
{
|
by: Keith Langer |
last post by:
I have a hashtable which is accessed by two threads. One thread does
all writing and enumeration in the hashtable, and the other thread has
read-only access to the table directly through keys but never with
enumerators. Is there any reason to worry about synclocks?
thanks,
Keith
|
by: jzlondon |
last post by:
Hi,
I have a question that I wonder if someone might be able to help me with...
I have an application which handles real-time financial data from a third
party source. The data comes in via events which are fired on an arbitrary
thread, and I then take the data, generate update commands for a SQL Server
database, and add them to a queue using a lock on a sync object to ensure
thread safety when writing to the queue.
| |
by: news.microsoft.com |
last post by:
Hi all,
Assume we have two entity class.
Class1:
Name: House
Property:
ID:int
Name:String
Desktops:Desktop
|
by: arun.darra |
last post by:
Are the following thread safe:
1. Assuming Object is any simple object
Object* fn()
{
Object *p = new Object();
return p;
}
2. is return by value thread safe?
|
by: Olumide |
last post by:
Hi -
I've got a class that contains static member functions alone, all of
whose arguments are passed by reference as shown below:
class MySpiffyClass{
// no constructor, destructor or variables, just static members
static void FirstFunction( args & );
static void SecondFunction( args & );
static void ThirdFunction( args & );
|
by: Henri.Chinasque |
last post by:
Hi all,
I am wondering about thread safety and member variables. If I have
such a class:
class foo {
private float m_floater = 0.0;
public void bar(){
m_floater = true;
}
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
| |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| |
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
| |