Java's Executor is (as far as I understand it) an abstraction over the ThreadPool concept - something that can accept and carry out (execute) tasks.
I'm looking for a similar exception for the Polling concept. I need to continuously poll (dequeue) items out of a specific Queue (which does not implement BlockingQueue), execute them and sleep, and repeat all this until shutdown.
Is there a ready-made abstraction or should I write something on my own?
(Suggestions of a better title are welcome)
Polling is easy:
Thread t = new Thread(new Runnable() {
public void run() {
try {
while (!t.isInterrupted()) {
Object item;
while ((item = queue.take()) == null) {//does not block
synchronized (lock) { lock.wait(1000L) } //spin on a lock
}
//item is not null
handle(item);
}
} catch (InterruptedException e) { }
}
});
t.start();
Perhaps you need to rephrase your question as I'm not quite sure exactly what it is you are trying to do?
Related
Recently I am working on a piece of code involving synchronization and struggling on how to test it. To get into the problem, we can consider we are writing a unit test for a CountDownLatch:
CountDownLatch l = new CountDownLatch(1);
new Thread() {
#Override
void run() {
l.await();
System.out.println("good!");
}
}.start();
Thread.sleep(1000); // wait for thread to run
if (the thread is alive)
l.countDown();
else
System.out.println("bad!");
So the problem is, there is no guarantee that the sleep for 1 second would be enough in all cases in all machines. So my goal is to eliminate this type of sleeping code to expect a certain state when testing synchronization, but soon realize it starts to become halting problem.
My current solution would be to query the state of the thread:
Thread t = ...
t.start();
if (t.getState() == Thread.State.WAITING) {
l.countDown();
assert(t.getState() == Thread.State.RUNNABLE); // or running or terminated
}
my questions are:
would that work? i.e. would the state of the thread will be toggled atomically at the moment, in this case, a count down latch reach a wakeup condition?(the doc says nothing about the change timing of the state)
do you have better suggestions?
Looking into your example I have a feeling that you're using countdown latch upside-down. Why can't you do something like that:
#Test
public void testThreads() throws Exception {
CountDownLatch l = new CountDownLatch(1);
new Thread(new Runnable() {
#Override
public void run() {
System.out.println("Parallel thread is doing something.");
try {
// instead of this sleep you put your logic that you want to be executed.
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
l.countDown();
}
}).start();
System.out.println("Main thread is waiting for parallel thread");
l.await();
System.out.println("Done.");
}
Please, correct me if I misunderstand your problem.
But generally speaking, I agree with one of the comments below your post that you should probably not test multithreading with unit tests.
My application has 1 global driver, which is responsible for doing the low-level work.
I then have 2 threads, both of which use infinite loops to get some work done. My question is how to allow 1 thread to use the driver as much as possible, but giving a chance to the second thread to use it when necessary.
To elaborate, the code I have is as follows:
public class Game {
private static final Object LOCK = new Object();
private static final Logger LOGGER = Logger.getLogger(Game.class);
private WebDriverController controller;
public Game(WebDriverController controler) {
this.controller = controller;
}
public void startThreadA() {
new Thread(new Runnable() {
#Override
public void run() {
while (true) {
synchronized (LOCK) {
controller.doSomethingA();
}
}
}
}).start();
}
public void startThreadB() {
new Thread(new Runnable() {
#Override
public void run() {
while (true) {
...
...
synchronized (LOCK) {
controller.doSomethingB();
}
...
...
}
}
}).start();
}
}
The logic is to allow the first thread to execute doSomethingA() as much as possible, with the second thread only acquiring the lock to complete little tasks and then giving the lock back to the first thread.
Using this code, the first thread will continuously use the controller to do what it needs to do, whereas the second thread gets stuck waiting at its synchronized block. The way I have currently fixed this is by adding a pause to the first thread, to give the second thread a chance to acquire the lock, as follows:
public void startThreadA() {
new Thread(new Runnable() {
#Override
public void run() {
while (true) {
synchronized (LOCK) {
controller.doSomethingA();
}
try {
Thread.sleep(1);
} catch (InterruptedException e) {
LOGGER.error(null, e);
}
}
}
}).start();
}
This does work exactly as intended, but it doesn't seem right. I'm not happy with the manual pause after each iteration, especially if the second thread does not need the lock as it's wasting time.
What do I replace the pause with to make this more efficient?
Why you use synchronized in run()? Use synchronized or Lock in your methods in WebDriverController.
public void doSomeThingA(){
lock.lock();
try {
//your stuff
} finally {
lock.unlock();
}
}
And in run method of Thread invoke these methods.
I think you are approaching this from the wrong direction, as in your current setup 99.999% of the time thread A calls for a monitor the processing time is wasted. However as I do not have enough details about your actual problem, here is a quick solution using a ReentrantLock with fair scheduling (FIFO):
protected final ReentrantLock lock = new ReentrantLock(true); // fair scheduling
public void functionA() {
lock.lock();
try {
controller.functionA();
} finally {
lock.unlock();
}
}
public void functionB() {
lock.lock();
try {
controller.functionB();
} finally {
lock.unlock();
}
}
Explanation:
If Thread A is currently holding the lock and Thread B calls, B is guaranteed to receive the monitor right after A releases it, even if A immediately (before any thread switch occurs) calls for it again.
There are a few options here. The best bet in this instance is likely to be remove the responsibility of deciding when to do work from the threads and instead, waiting for an event from a monitor to release the threads to do work. You can then schedule the work in whichever ratio is best suited to the purpose.
Alternatively, remove the lack of thread safety from your controller code.
Assuming that above thread organization is the best way to go for your particular case, your problem is that first thread holds the lock too long, thus starving the second one.
You can check if doSomethingA function really needs locked driver all the time while it is being executed (in most cases it doesn't), and if not split it into multiple smaller execution blocks, some of which hold the lock while other's don't. This will create more time for second thread to kick in when it needs to.
If that cannot be done then you really need to rethink your app, because you have created a resource bottleneck.
It looks like Thread.yield () is what you are looking for.
just a little question, i want to stiop the following thread, but i have no idea how i should do. Please help me. Googles help wasnt useful this time.
new Thread(){
public void run() {
while(!isInterrupted()){
try {
if (sock1!=null){
sock1.setTcpNoDelay(true);
if (btsar1.length > 0) {
dos1 = new DataOutputStream(sock1.getOutputStream());
bwrtr1 = new BufferedWriter(new OutputStreamWriter(
dos1), 300);
dos1.write(btsar1);
set1free = false;
Log.e("Communication", "written(1.1)");
Reader1.reader(4);}
}} catch (IOException e) {
e.printStackTrace();
}catch (NullPointerException e2){
e2.printStackTrace();
}
}
}}.start();
//.interrupt(); <-- or kinda that...
Can someone provide a good working thing, to stop this?
You just need a reference to your thread:
Thread t = new Thread(...);
Then you can interrupt it:
t.interrupt();
Thread t = new Thread(){
... // content unchanged
};
t.start();
.....
t.interrupt();
The best way to terminate a thread is to let it finish. So add a boolean flag in your while, and have method (or otherwise) expose it so it can be set to false. Then your thread would naturally exit after the interation has finished.
An idea: stop using anonymous threads!
Whenever you find yourself in a situation where your thread is doing something complicated, either create a separate class extending the thread, which can be used to control and monitor the behaviour, or use an abstract Future and a ThreadPool to do the work.
You will have an extremely unmaintainable and unextendable code if you keep using threads like this.
How to stop a thread gracefully?
bool keepWorking = true;
while(keepWorking) {
// keep working
}
synchronized void stopWork() {
keepWorking = false;
}
// in other thread
threadObj.stopWork();
Thread.interrupt method is for to stop a thread that waits for long periods (e.g., for input)
Take a look at this Article - How to Stop a Thread or a Task
example
public void stop() {
Thread moribund = waiter;
waiter = null;
moribund.interrupt();
}
I have a service that I would like to implement as a Google Guava Service.
The service basically runs a while (true) loop that processes events as they arrive on a BlockingQueue. Simplified sample code is available here:
https://gist.github.com/3354249
The problem is that the code blocks on BlockingQueue#take(), so the only way to stop the service is to interrupt its thread. Is this possible using Guava's AbstractExecutionThreadService?
Of course, in this case I could replace queue.take() with a polling loop using queue.poll(1, TimeUnit.SECONDS), thus removing the need for thread interruption. However:
I would like to avoid doing this, for both performance and code readability reasons
There are other cases where it is impossible to avoid thread interruption, e.g. if the service is blocked while reading bytes from an InputStream.
You can override executor() method to supply your own executor, which will then store reference to the thread into your field. Then you can easily interrupt the thread, if needed.
import java.util.concurrent.Executor;
import java.util.concurrent.Executors;
import java.util.concurrent.atomic.AtomicReference;
import com.google.common.util.concurrent.AbstractExecutionThreadService;
public abstract class InterruptibleExecutionThreadService extends AbstractExecutionThreadService {
private final AtomicReference<Thread> runningThread = new AtomicReference<Thread>(null);
#Override
protected Executor executor() {
return new Executor() {
#Override
public void execute(Runnable command) {
Thread thread = Executors.defaultThreadFactory().newThread(command);
runningThread.compareAndSet(null, thread);
try {
thread.setName(serviceName());
} catch (SecurityException e) {
// OK if we can't set the name in this environment.
}
thread.start();
}
};
}
protected void interruptRunningThread() {
Thread thread = runningThread.get();
if (thread != null) {
thread.interrupt();
}
}
}
I don't think interrupting the thread is really an option if you want to use an AbstractExecutionThreadService since there's not really any way to get a reference to the thread in order to call interrupt().
If you're using a BlockingQueue you either have to poll inside a while loop that checks if the service is still running, or you can use a sentinel value to alert the worker method that it needs to stop.
Examples:
Polling:
while(isRunning()) {
Value v = queue.poll(1, TimeUnit.SECONDS);
// do something with v
}
Sentinal value:
while(isRunning()) {
Value v = queue.take();
if(v == POISON) {
break;
}
// do something with v
}
I personally would try the polling solution and see what the performance is like. You might be surprised by how little that really effects the performance.
As for reading from an InputStream, if the InputStream is long-lived and has the potential to block indefinitely I don't think using an AbstractExecutionThreadService is really possible. You should instead use an AbstractService which creates and holds a reference to its own execution thread so that you can interrupt it in the doStop() method.
Started several worker threads , need to notify them to stop. Since some of the threads will sleep for a while before next round of working, need a way which can notify them even when they are sleeping.
If it was Windows programming I could use Event and wait functions. In Java I am doing this by using a CountDownLatch object which count is 1. It works but don't feel elegant, especially I have to check the count value to see if need to exit :
run(){
while(countDownLatch.count()>0){
//working
// ...
countDownLatch.wait(60,TimeUnit.SECONDS);
}
}
Semaphore is another choice, but also don't feel very right. I am wondering is there any better way to do this? Thank you.
Best approach is to interrupt() the worker thread.
Thread t = new Thread(new Runnable(){
#Override
public void run(){
while(!Thread.currentThread().isInterrupted()){
//do stuff
try{
Thread.sleep(TIME_TO_SLEEP);
}catch(InterruptedException e){
Thread.currentThread().interrupt(); //propagate interrupt
}
}
}
});
t.start();
And as long as you have a reference to t, all that is required to "stop" t is to invoke t.interrupt().
Use the builtin thread interruption framework. To stop a worker thread call workerThread.interrupt() this will cause certain methods (like Thread.sleep()) to throw an interrupted exception. If your threads don't call interruptable methods then you need to check the interrupted status.
In the worker thread:
run() {
try {
while(true) {
//do some work
Thread.sleep(60000);
}
}
catch(InterruptedException e) {
//told to stop working
}
}
Good way is to interrupt() threads, and inside thread make cycle like
try {
while (!Thread.interrupted()) {
...
}
} catch (InterruptedException e) {
// if interrupted in sleep
}
Keep in mind both cases when do interrupt:
if you sleep or wait then InterruptedException will be thrown;
in other cases interrupted flag will be set for the thread which you have to check yourself.
To have a pool of threads I would use the ExecutorService or a ScheduledExecutorService for delayed/periodic tasks.
When you want the workers to stop you can use
executorService.shutdown();
The other best approach would be to use interrupt( ) method.
E.g Here's how a thread uses this information to determine whether or not it should terminate :
public class TestAgain extends Thread {
// ...
// ...
public void run( ) {
while (!isInterrupted( )) {
// ...
}
}
}