Design Question dealing with Multithreading

[Guest]

Hello,

Just some background: I'm developing an application that basically executes
series of tasks. So far I have 2 group of tasks run on different threads (2
different threads). Which run in parallel. Now, these threads need read-only
access to app config settings Object. So, I have one public class with 1
static field - Hashtable which holds key/value configs settings. So far,
application runs in debug mode without any errors.
Is that a good design? Do I need to lock or synchronize access to that
static member? What's the "best practice" design for this kind of scenario?

Thank you for your help.

 

[DBC User]

Just curious, if the config file is readonly, do you need a lock? Also,
I was told ny experts to avoid static methods as much as possible.

 

[Nick Malik [Microsoft]]

You should not need to lock the hash table if all you are doing is reading
from it. However, when you are creating it, that activity should take place
in a single thread.

Why are you loading your config settings into a hash table anyway? Why not
directly from XML into an object? That is usually easier to read and runs
much faster, since there is no need to look up the key each time you want a
config setting?

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.

 

[Guest]

if the config file is readonly, do you need a lock

Without boring you with implementation details of this app. Default config
settings are stored in a file. But each user can and will change settings and
they get stored to IsolatedStorage, and loaded into a static field.
For the lifetime of an app config setting active threads do not access
config file or IsolatedStorage for this matter.

 

[Guest]

Thank you all.

Why are you loading your config settings into a hash table anyway? Why not
directly from XML into an object?

Like my own type or structure? I thought about it. But config keys might
change or new onse will be added. So, I don't want to keep changing this
object all the time. I want to be able load settings dynamicly into an
object; hashtable does that for me.

 

[Metallikanz!]

I believe Hashtable by default supports one writer and multiple readers concurrently. Even if you need multiple writer support, that's available too using the thread-safe wrapper returned by the Synchronized() static method.
The FW supports a special attribute class for the synchronization needs of static members, ThreadStaticAttribute - it's behavior is quite different from that of a static variable, have a look though.

HTH, Metallikanz!

 

[Guest]

I think the suggestion was to simply load the config into a config reader ...
for example:

/** ************************************** */
1. Create a static object for reading app.config file
/** ************************************** */

using System;
using System.Configuration;
using System.Xml;
using System.Windows.Forms;

sealed public class DynamicSettings
{
private static AppSettingsReader m_SettingsReader = null;
private static string m_ConfigFile = string.Empty;
private static XmlDocument m_XmlConfigurationFile = null;

static DynamicSettings()
{
m_SettingsReader = new AppSettingsReader();
m_ConfigFile = Application.ExecutablePath + ".config";
m_XmlConfigurationFile = new XmlDocument();
m_XmlConfigurationFile.Load(m_ConfigFile);
}

public static string GetString(string name)
{
return(((string)(m_SettingsReader.GetValue(name, typeof(string)))));
}
public static int GetInt(string name)
{
try
{
return(((int)(m_SettingsReader.GetValue(name, typeof(int)))));
}
catch { return(0); }
}
public static double GetDouble(string name)
{
try
{
return(((double)(m_SettingsReader.GetValue(name, typeof(double)))));
}
catch { return(0.0d); }
}
public static float GetFloat(string name)
{
try
{
return(((float)(m_SettingsReader.GetValue(name, typeof(float)))));
}
catch { return(0.0f); }
}
public static bool GetBoolean(string name)
{
try
{
return(((bool)(m_SettingsReader.GetValue(name, typeof(bool)))));
}
catch { return(false); }
}
public static void Set(string name, object value)
{
try
{
XmlNode node =
m_XmlConfigurationFile.SelectSingleNode("//configuration/appSettings/add[@key='" + name + "']");
node.Attributes["value"].Value = value.ToString();
m_XmlConfigurationFile.Save(m_ConfigFile);
}
catch { }
}
}

NOTE : I guess you have to be happy with static methods though ))
Also, you will have to litter the accessors with

lock(typeof(DynamicSettings))
{
// ...
}

--
Of all words of tongue and pen, the saddest are: "It might have been"

Bill.Richards @ greyskin .co .uk
http://greyskin.co.uk

 

[Nick Malik [Microsoft]]

Interesting design, Bill, but that wasn't my suggestion. The OP got it
right... I was suggesting that he create an XML structure and load the
config settings into memory.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

I think the suggestion was to simply load the config into a config reader
...
for example:

/** ************************************** */
1. Create a static object for reading app.config file
/** ************************************** */

using System;
using System.Configuration;
using System.Xml;
using System.Windows.Forms;

sealed public class DynamicSettings
{
private static AppSettingsReader m_SettingsReader = null;
private static string m_ConfigFile = string.Empty;
private static XmlDocument m_XmlConfigurationFile = null;

static DynamicSettings()
{
m_SettingsReader = new AppSettingsReader();
m_ConfigFile = Application.ExecutablePath + ".config";
m_XmlConfigurationFile = new XmlDocument();
m_XmlConfigurationFile.Load(m_ConfigFile);
}

public static string GetString(string name)
{
return(((string)(m_SettingsReader.GetValue(name,
typeof(string)))));
}
public static int GetInt(string name)
{
try
{
return(((int)(m_SettingsReader.GetValue(name, typeof(int)))));
}
catch { return(0); }
}
public static double GetDouble(string name)
{
try
{
return(((double)(m_SettingsReader.GetValue(name,
typeof(double)))));
}
catch { return(0.0d); }
}
public static float GetFloat(string name)
{
try
{
return(((float)(m_SettingsReader.GetValue(name,
typeof(float)))));
}
catch { return(0.0f); }
}
public static bool GetBoolean(string name)
{
try
{
return(((bool)(m_SettingsReader.GetValue(name, typeof(bool)))));
}
catch { return(false); }
}
public static void Set(string name, object value)
{
try
{
XmlNode node =
m_XmlConfigurationFile.SelectSingleNode("//configuration/appSettings/add[@key='"
+ name + "']");
node.Attributes["value"].Value = value.ToString();
m_XmlConfigurationFile.Save(m_ConfigFile);
}
catch { }
}
}

NOTE : I guess you have to be happy with static methods though ))
Also, you will have to litter the accessors with

lock(typeof(DynamicSettings))
{
// ...
}

--
Of all words of tongue and pen, the saddest are: "It might have been"

Bill.Richards @ greyskin .co .uk
http://greyskin.co.uk

Thank you all.


Like my own type or structure? I thought about it. But config keys might
change or new onse will be added. So, I don't want to keep changing this
object all the time. I want to be able load settings dynamicly into an
object; hashtable does that for me.

 

[Nick Malik [Microsoft]]

Thank you all.


Like my own type or structure? I thought about it. But config keys might
change or new onse will be added. So, I don't want to keep changing this
object all the time. I want to be able load settings dynamicly into an
object; hashtable does that for me.

Hi Lenn,

I agree with your approach. Don't optimize for speed until you are code
complete. However, if you are running your speed tests, and find you need
to improve, this approach may be useful.

Good luck,

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--