• Post Reply Bookmark Topic Watch Topic
  • New Topic

Thread Safety in a Single Instance of a class

 
Jane Smith
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
i have to redesign a class, say X, in such a way that i manage multiple threads accessing a single instance of the class, we cannot create multiple instances of X. The class looks like this:
Class X{
boolean isACalled=false;
boolean isInitCalled=false;
boolean isBCalled=false;

A(){

isACalled=true;
}
Init(){
if(!isACalled)
A();
B();
C();
isInitCalled=true;
}

B(){
if(!isACalled)
A();
isBCalled=true;
}

C(){
if(!isACalled)
A();
if(!isBCalled)
B();


}//end of class
Init is the method that would be invoked on the single instance of this class.
Now i cannot keep the flags as instance variables coz different threads would have differrent status of these flags at the same time, hence i can make them local, but if i make them local to one method, the others won't be able to check their status, so the only solution i can think of is to place all the flags in a hashtable local to method INIT AND INITIALIZE ALL OF them to false, as init would call other methods, it would pass the hashtable reference as an additional parameter, the methods would set the flags in the hashtable and it would be reflectecd in the original hashtable, and so all the methods can have access to the hashtable of flags and can perform their respective checks and setting of flags.
This all would be local to one thread, so there's no question of flags of one thread mixin with the flags of some other thread.

My question is :
Is this the best way, would this work?
In java, everything is pass by value, but if i pass the hashtable reference, would the changes made inside the called method to the hashtable key-value would be visible in the original hashtable declared inside the calling method of which the hashtable is local variable?

Thanks,
Newbie
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To allow several threads to access your class safely, you're going to need to use "synchronized" and/or "volatile". I suggest you read up on those key words in Sun's documentation of Java, or a good book.

If you are going to have an init() method that is allowed to be called more than once, and does nothing on second and subsequent calls (for extra points, that type of method is called "idempotent"), it should have a better name. I would go for something like ensureInitialised(); that name hints that it will do nothing if already initialised.

I notice also that you have methods with names starting with capital letters. This is perfectly legal, but most people consider it poor style. It will make your code look like "newbie" code. The standard naming for methods is to start with lower case letter and use "camel case" to indicate the start of new words in the name.

Finally, your login name is not to JavaRanch standards. A bartender will pick you up on this sometime and they will tell you that a real (sounding) name is not optional in JavaRanch. You may as well change it now, as you'll have to change it sometime, or risk account deletion.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also look at ThreadLocal. You could use one to hold an object that has all the variables for one thread. I don't see them recommended very often. Anybody have anything against them?
 
Jane Smith
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi, thanks for the reply, well the method and the class skeleton was given just to highlite the problem, the real code is too big to be pasted....
Thanks for the tips, neways.
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:
Also look at ThreadLocal.


ThreadLocal is great, but maybe not for this application.

ThreadLocal effectively implements a variable that has a separate value for each thread. It is inherently thread-safe. However, this application looks as if it wants to share data between threads; ThreadLocal's whole purpose is to avoid sharing data between threads.

I find ThreadLocal a good "get out of jail free" card for getting data from one part of my code, through some other code that I can't modify, to another part of my code.
 
Jane Smith
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi, actually the requirement would be satisfied by using Threadlocal, coz i want different threads to have their own data,as they may call the methods in any order and hence the flag values might be different for different threads.
But i have been told not to use threadlocal for soem reasons, maybe performance...as the no. of threads would be very high, maybe 1000's at a time.
I would have to use the hashtable,as suggested in the original post...would that work, can you have a look at the solution i had proposed in the post containing the question?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Passing all the state from one method to another is indeed another choice. I wind up doing it in servlets all the time.

I'd pass on the Map idea, though, and make a little class that holds named fields. A Map is wonderfully flexible, but doesn't tell readers anything about what's in it. A little object with well-named variables would communicate your intent a lot better.

Are A() B() and C() public? Called in other contexts from within this class? If so, callers would have to know to pass the flags along. If not, this logic looks unnecessary - if they can only be called in sequence from init() why bother?

BTW: Thousands of threads "at a time" sounds like an issue. Run a quick test and make sure your target platform can even spawn that many!
[ June 26, 2007: Message edited by: Stan James ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!