global objects

  • Thread starter Thread starter parez
  • Start date Start date
P

parez

Hi ALL!


I am feeling kinda lost here.How do i make global objects available to
a class.


e.g i want to make some objects available like the httpcontext object
available if you run a component under asp.net.


Thanks in advance


ps
 
The question you are asking is:

"How do I implement singleton pattern?"
here is how:

//seal the class so it can't be inherited
sealed public class MySingleton
{

// instance of MySingleton that will be global to the app
// note it is static!!!
static MySingleton _context;
// some field containing data for demo purposes
string _data;
// hide the constructor
private void MySingleton {}
// static property to return the global instance
static public void MySingleton Context
{
get
{
//lock the type for thread safety
lock( typeof(MySingleton)
{
//instance it if it has never been instanced
if (_context = null) _context = new MySingleton();
}
//return the global instance
return _context;
}
}

// statndard property to return data that MySingleton manages
public void string Data
{
get
{
return _data;
}
set
{
lock(this)
{
_data = value;
}
}
}
}

usage:

MySingleton.Context.Data = "foobar";
Console.Writeline(MySingleton.Context.Data);

read this:
http://en.wikipedia.org/wiki/Singleton_pattern
buy this:
http://en.wikipedia.org/wiki/Design_Patterns
 
this line:
if (_context = null) _context = new MySingleton();
should read
if (_context == null) _context = new MySingleton();
 
Hi Joe!

That is exactly what i wanted .. and yes it is singleton pattern ...
and yes.. i had a brain fart...
I am planning to use singleton for a caching layer that i am working
on .. what do you think that ?

Thanks for the example...

PS
 
first many typos in my singleton. . .

here's the real code. . .

sealed public class MySingleton
{
static MySingleton _context;
string _data;
private MySingleton (){}
static public MySingleton Context
{
get
{
//lock the type for thread safety
lock( typeof(MySingleton))
{
//instance it if it has never been instanced
if (_context == null) _context = new MySingleton();
}
//return the global instance
return _context;
}
}
public string Data
{
get
{
return _data;
}
set
{
lock(this)
{
_data = value;
}
}
}
}
Locking the singleton type is slightly dangerous - it's a public
reference, effectively, so other things may lock the same reference.

I guess its something to worry about if for some stupid reason you expect
someone who uses your assembly to write a piece of code that is effectively:

lock(typeof(MySingleton)){ while (true){} };

But if I spent all my time trying to account for every moronic case in which
someone could break something, I wouldn't get anything done.

The fault here is not with the code of MySingleton but in the logic of the
use of MySingleton. The type was locked and they entered an infintite loop
condition.

Also if you prevent "lock(typeof(MySingleton))" from blocking access to
'Context', it would actually obfuscate the infinite loop condition, would it
not????
And wouldn't that make debugging harder if the moron created the condition.
For all intents and purposes, the application would appear to be working in
all other threads, and the fact that the loop never terminated would not be
apparent to the developer.

Am I wrong???
 
I guess its something to worry about if for some stupid reason you expect
someone who uses your assembly to write a piece of code that is effectively:

lock(typeof(MySingleton)){ while (true){} };

But if I spent all my time trying to account for every moronic case in which
someone could break something, I wouldn't get anything done.

The fault here is not with the code of MySingleton but in the logic of the
use of MySingleton. The type was locked and they entered an infintite loop
condition.

Keeping your locks private is just a good practice thing to do. Hey, it
might not hurt if you left all your fields public, too, but I don't
think that's a good idea either.
Also if you prevent "lock(typeof(MySingleton))" from blocking access to
'Context', it would actually obfuscate the infinite loop condition, would it
not????

No, because you use:

lock (someLock)

where someLock is defined as:

static object someLock = new object();

(and obviously you call someLock whatever you want to).
And wouldn't that make debugging harder if the moron created the condition.
For all intents and purposes, the application would appear to be working in
all other threads, and the fact that the loop never terminated would not be
apparent to the developer.

Am I wrong???

Yes, because you could easily end up in a deadlock situation without it
being totally moronic - or at least any worse than the singleton code
itself. Locks just *should not* be held on publicly available
references unless they're exposed specifically for the purpose of
locking.

You could easily end up with code which locks on the type reference in
one thread, but relies on another thread (perhaps without even knowing
it!) accessing the singleton. Bang - deadlock, all because you couldn't
be bothered to make it lock on a private reference. Yes, it would still
be foolish of the other developer to have locked on the type in the
first place, but your code currently makes that code more likely to be
a problem.
 
so is this adequate????

public class MySingleton
{
static MySingleton _instance;
private class Syncroot {};
public static MySingleton Instance
{
get
{
lock(typeof(syncroot))
{
if (_instance == null) _instance = new TestApp();
}
return _instance;
}
}
}
 
joe mamma said:
so is this adequate????

public class MySingleton
{
static MySingleton _instance;
private class Syncroot {};
public static MySingleton Instance
{
get
{
lock(typeof(syncroot))
{
if (_instance == null) _instance = new TestApp();
}
return _instance;
}
}
}

Yes, that would do - but why bother creating a whole extra type when a
static variable would work just as well?
 
Back
Top