What is the scope of a 'static' variable?

[Gery D. Dorazio]

Gurus,

If a static variable is defined in a class what is the scope of the variable
resolved to for it to remain 'static'? For instance, lets say I create a
class library assembly that is strongly name which contains the class where
the static variable is defined. This library can be referenced by multiple
projects. I am fairly sure the static variable does not survive across the
application boundry but does it within the application boundry and/or the
domain boundry? Maybe another way to word this question is this: To what
scope is an instance object defined?

Thanks,
Gery


--
Gery D. Dorazio
Development Engineer

EnQue Corporation
1334 Queens Road
Charlotte, NC 28207
(704) 377-3327

 

[Michael C#]

Hmmm... static is not a scope modifier itself. It can be used with scope
modifiers like 'public' though. The scope of the static variable is
whatever you defined it as with your scope modifier... A public static
variable would have the same scope as a public variable. Not sure if that
answers your question, but I'm not quite sure I understand the question
Sorry bout that, if it doesn't...

 

[Gery D. Dorazio]

I think I confused the issue by not understanding the managed code
architecture. After doing some reading just now, as I understand it, an
'application domain' is what the common language runtime defines as the
boundry for object activations within the same scope. Then MS defines that
scope as the application scope. With that, they also say that multiple
application domains can exist in a single process...this was the area that
confused me with regard to this initial idea of how far 'static' variables
extend. So it looks like the old application scope/domain is the key
here....only one instance of a static variable will exist in the application
domain for all object instantiations...this is the conclusion. But what
prompted this is the following work that I am trying to make robust:

I am trying to do is create an orderly way to access XML files which really
act similarly to tables in a database. There are multiple control files in
multiple directories which are collectively related to a higher level folder
with another control file....e.g. similar to a parent-child table
relationship schema. To access these files currently I use something like
this:

private static object _lockCtrlFileHandle = new object();

and then in various methods:

lock(_lockCtrlFileHandle)
{
...do something...
}


The problem (I think but am not sure) with this approach is that I don't
think it will scale well and it may actually come to a screeching halt with
a large number of users(deadlock). But another question that comes up is how
access to the files should be handled by different applications...the
'static' object lock handle above only works for the application it is
running in. (I think...)

But the next question that comes to mind is that Windows already manages
file handles. It gives an error message when accessing the same file when it
is opened exclusively by another application. I think this is actually built
into file IO perhaps in BIOS.

So maybe the question is really how do I design a file access system that
keeps an orderly access and control for the information thats in those
files?

Thanks for your response. If you have more ideas about this I would
appreciate hearing them.

Thanks,
Gery

--
Gery D. Dorazio
Development Engineer

EnQue Corporation
1334 Queens Road
Charlotte, NC 28207
(704) 377-3327

 

[Sean Hederman]

Gurus,

If a static variable is defined in a class what is the scope of the
variable resolved to for it to remain 'static'? For instance, lets say I
create a class library assembly that is strongly name which contains the
class where the static variable is defined. This library can be referenced
by multiple projects. I am fairly sure the static variable does not
survive across the application boundry but does it within the application
boundry and/or the domain boundry? Maybe another way to word this question
is this: To what scope is an instance object defined?

Static variables are stored in the assembly data sections. Each time an
assembly is loaded into an app-domain new data and code sections are created
for it. In the case of a domain-neutral assembly, it is loaded into the
SharedDomain only. This theoretically would result in the statics being
shared across the AppDomains that reference the assembly, but the CLR does
some bookkeeping to avoid this.

So simply, the answer is that static variables's values exist in an
AppDomain.

 

[Sean Hederman]

[Snip]

I am trying to do is create an orderly way to access XML files which
really act similarly to tables in a database.

Just as a note, this is a really bad use of XML, it's not designed to
replace databases at all.

But another question that comes up is how access to the files should be
handled by different applications...the 'static' object lock handle above
only works for the application it is running in. (I think...)
Correct.

But the next question that comes to mind is that Windows already manages
file handles. It gives an error message when accessing the same file when
it is opened exclusively by another application. I think this is actually
built into file IO perhaps in BIOS.
Correct.

So maybe the question is really how do I design a file access system that
keeps an orderly access and control for the information thats in those
files?

I'd suggest creating a service to provide the information. Thus, all file
I/O would be confined to the service, and thus it could control things
itself. The consumers of the service would simply indicate the data they
wanted and be provided with it.

This would also allow you to build in such things as caching, so if a
frequently requested file was read twice in a row, you'd actually be reading
it from the RAM the second time round. In such scenarios it's importrant
that if the file is written to, the cache is flushed. However if all
communication with the files goes through your service this should not be
difficult to implement.