Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Threads updating a static variable  RSS feed

 
Sarat Burle
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I have a requirement to restrict the number of active threads.

I have 3 classes, say A, B & C. B implements Runnable. C has a class level static variable, say, 'count'. 'A' has the main method.

When 'A' starts, it spawns threads of B, lets say 2 in number. B increments the value of the variable 'count'. After this, A terminates.

Now, again if 'A' is started, then before spawning the thread for 'B', what should be the value of the variable 'count'? Should it be '0' or '2'?

I am getting '0' but I was expecting '2'.

Is there something wrong or my expectation is incorrect?

Please let me know.

Thanks,
Sarat.
 
Stefan Wagner
Ranch Hand
Posts: 1923
Linux Postgres Database Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since we don't know how B increments count, how should we tell?

This code will show 0.
if you change it:

It will display 2.
[ August 28, 2004: Message edited by: Stefan Wagner ]
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One way to limit the number of threads is to use a thread pool. Make threads that wait for commands that they can run. Any time you want to run some code on another thread you put a command containing the code in a queue and the next available thread gets it from the queue and runs it. You could keep a constant number of threads in the pool or let it grow and shrink over time. Look into thread pools in Java Tiger 5.0, Doug Lea's thread packages or the Apache Commons Thread Pool.

Regarding the static counter ... you could use that technique to increment it every time a thread starts, but be sure to decrement it when the thread ends.

To limit the number of threads running you'd have to do some kinda tricky stuff:

The next challenge is interrupting this thing when we decrement the counter. Lemme know if you think of a good way to do that!
[ August 28, 2004: Message edited by: Stan James ]
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mind your synchronization, gentlemen. On the face of it none of the code above is threadsafe

- Peter
 
Sarat Burle
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for the replies.

Stefan, I am incrementing the count in the run method. But my question was what would be the value when class A is run for the second time (assuming that the threads have incremented the value in the first run of A)?

Stan, I am sure going to decrement the count when the thread completes its processing. The incrementing part was just for testing.

Peter, if I have synchronized decrement & increment methods for variable (after making the variable private), I think the code would be thread-safe then. But is there a way to simulate the error that would arise due to
non-thread-safe code?
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Sarat Burle:
But is there a way to simulate the error that would arise due to
non-thread-safe code?
Not easily in this case, since the critical section is so small (between the load-increment-store operation in counter++). You can sort-of simulate it by coding out your increments and decrementsand putting a Thread.sleep() in between:Then running the result with a couple of threads.

- Peter
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Peter den Haan:
Not easily in this case, since the critical section is so small (between the load-increment-store operation in counter++).


To make it even more complicated, wether you get an error might also heavily depend no the runtime environment. For example problems arising from cached memory not being updated with current values might only occur with certain VMs on multiprocessor systems...
 
Stefan Wagner
Ranch Hand
Posts: 1923
Linux Postgres Database Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Peter: I got the impression, that Sarat is very fresh to threads, and jumping to syncronization is to far jumped.

Sarat:
1. post:
'A' has the main method.

2. post:
But my question was what would be the value when class A is run for the second time


If you don't run A from the same JVM (which is the normal situation), you get a separate room, with a new static C.count, which doesn't know anything about the other JVM, and the C.count used by it.
 
m qasim
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
using join() on B's threads before instantiating a new A will let B complete it's increments properly.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!