static and threads

[Wizumwalt]

Anyone know any good articles that talk about static members and
threads. I want to know if I declare any members of a class as static,
can it be seen in other threads, or how they might be seen across
threads, is the vm dependent, or if I shouldn't do this at all ...

Any help much appreciated.

 

[Oliver Wong]

Anyone know any good articles that talk about static members and
threads. I want to know if I declare any members of a class as static,
can it be seen in other threads, or how they might be seen across
threads, is the vm dependent, or if I shouldn't do this at all ...

I typed in "java static thread" into Google and got back
http://www.javaworld.com/javaworld/jw-04-1999/jw-04-toolbox.html

- Oliver

 

[John C. Bollinger]

Anyone know any good articles that talk about static members and
threads. I want to know if I declare any members of a class as static,
can it be seen in other threads, or how they might be seen across
threads, is the vm dependent, or if I shouldn't do this at all ...

Your question doesn't make sense. Threads other than which?

Anyway, you need to recognize that classes are scoped to the VM(*), and
that threads are are largely an orthogonal issue. I tend to frown on
non-final static fields in general, and especially in an intentionally
multi-threaded context, but it has nothing to do with lack of
visibility. Quite the opposite, in fact.

If you are programming with threads then you will simplify your life and
reduce your bug count by reducing the number of shared variables as much
as possible. Static fields are particularly nasty in this respect
because not only are they potentially shared by any thread in the VM,
but also *you have no way to control the sharing*. Contrast instance
variables, where you can control sharing by keeping a rein on references
to their containing object. Even better vis a vis threading are local
variables and method arguments, which are guaranteed to not be visible
to exactly one thread.


(*)Yes, I know about ClassLoaders, but they're not much relevant to the
question at hand.

 

[Roedy Green]

Static fields are particularly nasty in this respect
because not only are they potentially shared by any thread in the VM,
but also *you have no way to control the sharing*.

Why don't the same tactics you use for instance members work, namely
locking the class objects with synchronized or locking a static lock
object to represent locking just a group of static fields?

 

[Roedy Green]

Static fields are particularly nasty in this respect
because not only are they potentially shared by any thread in the VM,
but also *you have no way to control the sharing*.

Granted you have more contention for shared static fields, but
sometimes the field ARE shared and that's just tough.

 

[Roedy Green]

Anyone know any good articles that talk about static members and
threads. I want to know if I declare any members of a class as static,
can it be seen in other threads, or how they might be seen across
threads, is the vm dependent, or if I shouldn't do this at all ...

threads and visibility have almost nothing to do with each other. The
only thread-specific rule I can think of is that local variable are
visible only to the current member/thread. There is one copy of the
locals for each thread/method/recursion instance.

 

[John C. Bollinger]

Why don't the same tactics you use for instance members work, namely
locking the class objects with synchronized or locking a static lock
object to represent locking just a group of static fields?

I think I failed to put my point in the clearest terms. Please indulge
me as I try again: you can *cooperatively* control access to a static
field via synchronization, but the only way to *pre-emptively* control
access to any java entity is to control its visibility, and that simply
isn't an option for static fields. Cooperative access control is
susceptible to bugs and even intentional abuse. There's no getting
around that; it's the price of using shared variables. That price can
be mitigated with instance variables by controlling the instance they
are associated with, but there is no such possibility for static fields.

 

[John C. Bollinger]

Granted you have more contention for shared static fields, but
sometimes the field ARE shared and that's just tough.

If you're talking about third-party software then yes, you may just find
yourself out of luck. If the software is under your control, however,
then it's never "just tough". It may be a poor design choice that you
are now stuck with, but I claim that there is /always/ an alternative to
mutable static fields in a de novo design. Indeed, always an
alternative to static fields of any stripe, though some varieties are
mostly harmless.

 

[Chris Uppal]

you can *cooperatively* control access to a static
field via synchronization, but the only way to *pre-emptively* control
access to any java entity is to control its visibility, and that simply
isn't an option for static fields.

I'm a bit puzzled about what you mean here. It is certainly possible (as you
are, beyond doubt, fully aware) to implement shared state as a private static
field, and only provide access via synchronised methods. Perhaps you are
referring to the fact that instances would still be able to "get at" the static
field directly in such a scenario ? If so the picture doesn't seem all /that/
scary to me -- after all instances can also get at other instances' private
parts, and it doesn't seem to cause too many problems (not even with
synchronisation).

-- chris

 

[Oliver Wong]

It may be a poor design choice that you are now stuck with, but I claim
that there is /always/ an alternative to mutable static fields in a de
novo design. Indeed, always an alternative to static fields of any
stripe, though some varieties are mostly harmless.

How would you implement counting the number of times an object of a
given class was instantiated without using static fields? Code snippet to
illustrate what I mean:

public class Foo() {
private static int timesInstantiated = 0;

public Foo() {
timesInstantiated++;
}

public int getNumberOfTimesInstantiated() {
return timesInstantiated;
}
}

- Oliver

 

[John C. Bollinger]

How would you implement counting the number of times an object of a
given class was instantiated without using static fields? Code snippet to
illustrate what I mean:

[Code elided]

If I needed that information then I would use a factory to obtain
instances, and record the count in the factory instance's state.

 

[John C. Bollinger]

John C. Bollinger wrote:




I'm a bit puzzled about what you mean here. It is certainly possible (as you
are, beyond doubt, fully aware) to implement shared state as a private static
field, and only provide access via synchronised methods. Perhaps you are
referring to the fact that instances would still be able to "get at" the static
field directly in such a scenario ? If so the picture doesn't seem all /that/
scary to me -- after all instances can also get at other instances' private
parts, and it doesn't seem to cause too many problems (not even with
synchronisation).

My argument is thread-centric, not object-centric, but yes, you have
touched on a key issue in the area. You're also right that if you
swaddle a static field in enough insulation then it's not much of a
thread-safety hazard, but my overall point -- perhaps a bit overstated
-- was that static fields require more care relative to multithreaded
programs than any other kind of Java variable.

 

[Chris Uppal]

[...] if you
swaddle a static field in enough insulation then it's not much of a
thread-safety hazard,

"swaddle", nice choice of word.

but my overall point -- perhaps a bit overstated
-- was that static fields require more care relative to multithreaded
programs than any other kind of Java variable.

Perhaps an alternative way of phrasing that would appeal: static fields require
as much care as any other field, but they don't always get it.

I mean we don't like to see objects with their fields hanging out naked to the
breeze; why should classes be any different ?

-- chris

 

[Oliver Wong]

How would you implement counting the number of times an object of a
given class was instantiated without using static fields? Code snippet
to illustrate what I mean:

[Code elided]

If I needed that information then I would use a factory to obtain
instances, and record the count in the factory instance's state.

I didn't think of that! =)

However, the information might not be exactly the same, since presumably
each instance of the factory will keep records for the instances of Foo that
IT creates. So if Foo is created 5 times, 3 times by factory A, 2 times by
factory B, there isn't a direct way to get the value "5".

- Oliver

 

[John C. Bollinger]

Oliver Wong wrote: [...]

How would you implement counting the number of times an object of a
given class was instantiated without using static fields? Code snippet
to illustrate what I mean:

[Code elided]

If I needed that information then I would use a factory to obtain
instances, and record the count in the factory instance's state.

I didn't think of that! =)

However, the information might not be exactly the same, since presumably
each instance of the factory will keep records for the instances of Foo that
IT creates. So if Foo is created 5 times, 3 times by factory A, 2 times by
factory B, there isn't a direct way to get the value "5".

Yes, but if you want to be able to get the value "5" then you create all
the needed instances with the same factory. It is eminently possible to
structure an application so that this happens.

Overall, you can formulate an implementation problem with enough
conditions that a static variable and/or method is far and away the most
convenient Java implementation approach, but such is never the only
possible approach. Whatever static member you postulate can be
implemented instead as an instance member of a different class. The
only exception I know of is the main() method of an application, which
Java itself explicitly requires to be static.

 

[Chris Uppal]

Yes, but if you want to be able to get the value "5" then you create all
the needed instances with the same factory. It is eminently possible to
structure an application so that this happens.

Without using static fields /anywhere/ ?? The only ways that I can think of
would either involve passing a reference to the factory as a parameter to every
method call in every calling chain from main() to the point where the factory
was used, or doing something similar to ensure that all objects (that needed
them) would have a reference to the factory held in their instance state.

Not what /I/ would call "eminently possible" ;-)

(Not a serious point, John, I'm just being pedantic...)

-- chris

 

[Oliver Wong]

Overall, you can formulate an implementation problem with enough
conditions that a static variable and/or method is far and away the most
convenient Java implementation approach, but such is never the only
possible approach. Whatever static member you postulate can be
implemented instead as an instance member of a different class. The only
exception I know of is the main() method of an application, which Java
itself explicitly requires to be static.

Okay, here's the next situation I've concocted where I can't figure out
how to implement it without using statics. Let's say you have some sort of
hardware hooked up to your computer (e.g. a webcam, atom decay-sensor,
joystick, etc.) and you want a class to act as an abstraction of that
hardware. Since you only have one copy of that hardware, you'd like to
ensure only one instance of that class binds to the hardware (assume
something disastrous happens if two instances tries to bind to the same
hardware). Can you design a robust class library for this without using
statics?

- Oliver

 

[E11]

Use the singleton pattern?



Regards,
Edwin

 

[Oliver Wong]

Use the singleton pattern?

How do you implement the singleton pattern without using statics then?

- Oliver

 

[E11]

Well, you can't implement the singleton pattern without using statics
at all.

OK, i guess i'm a little OOP here given that the discussion is about
whether there is always a non-statics alternative to a design that uses
statics.



Regards,
Edwin