static variables in global.asax

[Kalpesh]

Thanks Scott for clearing my understanding

I understood that CLR takes care of thread safety, when static is
prefixed
My misunderstanding

Also, it is not that I do not understand the static properties (eg.
Environment.NewLine)
I am curious to understand where would you provide read/write static
properties ?
(Environment.NewLine is a read only thing)

Also, which is better, properties or methods & why ?
For eg. Outlook has ActiveInspector - which sounds like a property, but
is a method
What is the reasoning when a library developer can make something like
this as property
What is the reason for such a decision ?


In your example, Database db = Factory.DatabaseInstance doesnt allow to
change the underlying value, using singleton

Kalpesh

 

[Kalpesh]

Kevin,

I do understand the difference between static & instance members
But, it is always good to learn & see with a new perspective

Thanks for explaining it in a simple manner.
I agree that developer has to take care of locking even in case of
static members

The threading guideline says
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Do not provide static methods that mutate static state.

Do make all static state thread safe.

If you must use static state, make it thread safe. In common server
scenarios, static data is shared across requests, which means multiple
threads can execute that code at the same time. For this reason it is
necessary to protect static state
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Scott cleared my confusion by his article

See my response to Scott on what is the purpose of static properties ?
I understand what static property is. But, dont understand the use of
it (for read/write purpose) ?
As Scott said, it can be achieved using Singleton pattern

Thanks
Kalpesh

 

[Kalpesh]

Sahil,

In your case, I assume it is a readonly operation that you will be
doing (static readonly property)
So, I assume that it is threadsafe (since it doesnt allow write
operations)

Scott/Kevin: Do you agree ?

Kalpesh

 

[Kevin Spencer]

Any data that is read-only is thread-safe.

It is important to ensure that it is read-only. This can be done with fields
by using the "readonly" modifier, as in:

public static readonly string foo = "bar";

You can also initialize the value of a static field in the static
constructor for the class that contains it:

public class foobar
{
public static readonly string foo = "bar";

static foobar
{
foo = "bar";
}
}

Another alternative is to create a private static field that is exposed by a
public static accessor.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
If you push something hard enough,
it will fall over.
- Fudd's First Law of Opposition

 

[Richard Blewett [DevelopMentor]]

Any data that is read-only is thread-safe.

One thing to be careful of (its bitten me in the past) is that something you
think would be readonly turns out not to be.

DataView.Select was the one that bit me

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

 

[Scott Allen]

Also, which is better, properties or methods & why ?

I'd say it's not a choice between which is better, but which fits the
design. There are some guidelines in the following post under "General
Design Guidelines":
http://blogs.msdn.com/kcwalina/archive/2004/09/28/235232.aspx

You probably won't find any static read / write properties because
it's tough to make them thread safe. You generally need a
synchronization primitive to span both the read and write operations,
which isn't possible with get and set (unless it's done in a very
dangerous way).

For eg. Outlook has ActiveInspector - which sounds like a property, but
is a method
What is the reasoning when a library developer can make something like
this as property
What is the reason for such a decision ?

Ugh - the Office object model is hideous and was designed in a
different era. I wouldn't follow it's design at all