The language is Java and the question : having some application listening on a port, and this application is multithreaded, having threads kept in a ThreadLocals Set.Can I by opening a socket to stream and transfer a file, can I open the socket and deliver it to the specific thread ? The application already transfers specific serializable objects of X-interface between sockets.
I am agree with Peter. But if you stepped back, validated your design and decided that you really need this I think you can do it as following.
You should add to your protocol any indication of thread. Let's say that you call your threads 1, 2, 3 etc. So, each command being sent from client should contain the thread ID it is dedicated to. The listening thread should extract this value and submit task to specific thread. I have no idea whether you can do it using existing thread pools you you need your own. But no worries: if your thread pool is simple (i.e. is not changing number of threads dynamically etc) it is just a 10 code lines to write your own thread pool: create list of threads List<Thread>, and write loop that fills it: threads.add(new Thread()).
Each thread should wait on its own queue of Runnables. When new task arrives to Thread #n, just create runnable and put it into corresponding queue.
The simplest way to have a worker thread is to use a ExecutorService which is single threaded (or a pool if you wish) You can then give it tasks with
ExecutorService executor = Executors.newSingleThreadExecutor();
executor.execute(new Runnable() { ... });
executor.shutdown();
Not sure why you would keep Threads in ThreadLocal variables. Perhaps it is time to take a step back from your design and ask yourself if you can do this in a simpler way.
Related
Looking for an approach to solve a multi threading problem.
I have N number of tasks say 100. I need to run this 100 tasks using limited number of threads say 4. Task size is huge , so I dont want to create all the tasks together. Each task will be created only when a free thread is available from the pool. Any recommended solution for the same.
You could use a BlockingQueue to define the tasks. Have one thread create the tasks and add them to the queue using put, which blocks until there's space in the queue. Then have each worker thread just pull the next task off of the queue. The queue's blocking nature will basically force that first thread (that's defining the tasks) to not get too far ahead of the workers.
This is really just a case of the producer-consumer pattern, where the thing being produced and consumed is a request to do some work.
You'll need to specify some way for the whole thing to finish once all of the work is done. One way to do this is to put N "poison pills" on the queue when the generating thread has created all of the tasks. These are special tasks that just tell the worker thread to exit (rather than doing some work and then asking for the next item). Since each thread can only read at most one poison pill (because it exits after it reads it), and you put N poison pills in the queue, you'll ensure that each of your N threads will see exactly one poison pill.
Note that if the task-generating thread consumes resources, like a database connection to read tasks from, those resources will be held until all of the tasks have been generated -- which could be a while! That's not generally a good idea, so this approach isn't a good one in those cases.
If can get the number of active threads at a certain point of time from the thread pool you can solve your problem. To do that you can use ThreadPoolExecutor#getActiveCount. Once you have the number of the active thread then you can decide you should create a task or not.
ThreadPoolExecutor executor = (ThreadPoolExecutor) Executors.newFixedThreadPool(5);
executor.getActiveCount();
Note: ExecutorService does not provide getActiveCount method, you
have to use ThreadPoolExecutor. ThreadPoolExecutor#getActiveCount
Returns the approximate number of threads that are actively
executing tasks.
I have an piece of code which writes an object to disk as an when the object is put into the LinkedBlockingQueue.
As of now, this is Single threaded. I need to make it multi threaded as the contents are being written to the different files on disk.and therefore, there is no harm in writing them independently.
I am not sure if i can use ThreadPool here as i dont know when the object will be placed on the queue!! now if i decide to have a fixedThreadPool of 5 threads, how do i distribute it among multiple objects?
Any suggestions are highly appreciated.
here is my existing code. I want to Spawn a new thread as and when i get a new object in the queue.
how do i distribute it among multiple objects?
Well, you don't have to worry about task distribution. All you need to do is submit a runnable or callable(which describes your task) and it will be handed to an idle thread in the pool or if all the threads are busy processing, this new task will wait in queue.
Below is what you can try...
1) Create a thread pool that suits your need best.
ExecutorService es = Executors.newFixedThreadPool(desiredNoOfThreads);
2) As you already have the queue in place -
while (true) {
//peek or poll the queue and check for non null value
//if not null then create a runnable or callable and submit
//it to the ExecutorService
}
Generally speaking, if your files are on the same physical device you will get no performance benefit since storage devices work synchronously on read/write operations. So your will get your threads blocked on I/O, which can lead to poorer speed, and definitely will waste threads that could be doing useful work.
I am creating thread pools like this:
ExecutorService workers = Executors.newCachedThreadPool();
Invoking each pool tasks like this:
workers.invokeAll(tasks);
And after completion shutting those down like this:
workers.shutdown();
I have about 4 thread pools that do different procedures and those thread pools are being created from a servlet class.
What I want to do is shutdown all threads in those thread pools.
What is the cleanest way to achieve this?
Thanks
If all your worker tasks handle interrupts properly you could try to invoke:
workers.shutdownNow()
That call with typically send interrupts too all worker threads. However, proper interrupt handling is a bit implicit and the method documentation says that only a best effort attempt to stop the tasks is made. Hence, some JVM implementations might make a worse attempt than sending interrupts, why you might not want to trust this call.
You might want to look into other answers how to gracefully ensure proper shutdown of threads and implement such a solution for all your worker tasks, to guarantee proper shutdown. For example, in this answer, Jack explains the typical solution to have a volatile field that you can check in your workers. This field can be set from where you want to stop your tasks.
I'm new to this concurrent programming in java and came up with following scenarios where I'm getting confusion which to use when.
Scenario 1: In the following code I was trying to run threads by calling .start() on GPSService class which is a Runnable implementation.
int clientNumber = 0;
ServerSocket listener = new ServerSocket(port);
while (true) {
new GPSService(listener.accept(), clientNumber++, serverUrl).start();
}
Scenario 2: In the following code I was trying to run threads by using ExecutorService class as shown
int clientNumber = 0;
ServerSocket listener = new ServerSocket(port);
while(true) {
ExecutorService executor = Executors.newSingleThreadExecutor();
executor.execute(new GPSService(listener.accept(), client++, serverUrl));
executor.shutdown();
while (!executor.awaitTermination(1, TimeUnit.SECONDS)) {
// Threads are still running
System.out.println("Thread is still running");
}
// All threads are completed
System.out.println("\nThread completed it's execution and terminated successfully\n");
}
My Questions are
Which is the best practice to invoke a thread in concurrent programming?
What will be result(troubles) I'll end up with when I use first or second?
Note: I've been facing an issue with the first scenario where the program is getting hanged after every few days. So, is that issue related/expected when I use first method.?
Any good/helpful answer will be appreciated :) Thank you
There are no big differences in the two scenario you posted, except from managing thread termination in Scenario2; you always create a new thread for each incoming request. If you want to use ThreadPool my advice is not to create one for every request but to create one for each server and reuse threads. Something like:
public class YourClass {
//in init method or constructor
ExecutorService executor = Executors....;// choose from newCachedThreadPool() or newFixedThreadPool(int nThreads) or some custom option
int clientNumber = 0;
ServerSocket listener = new ServerSocket(port);
while(true) {
executor.execute(new GPSService(listener.accept(), client++, serverUrl));
}
This will allow you to use a thread pool and to control how many threads to use for your server. If you want to use a Executor this is the preferred way to go.
With a server pool you need to decide how many threads there are in the pool; you have different choices but you can start or with a fixed number or threads or with a pool that tries to use a non busy thread and if all threads are busy it creates a new one (newCachedThreadPool()). The number of threads to allocate depends form many factors: the number of concurrents requests and it durations. The more your server side code takes time the more you need for additional thread. If your server side code is very faster there are very high chances that the pool can recycle threads already allocated (since the requests do not come all in the same exact instant).
Say for example that you have 10 request during a second and each request lasts 0.2 seconds; if the request arrive at 0, 0.1, 0.2, 0.3, 0.4, 0.5, .. part of the second (for example 23/06/2015 7:16:00:00, 23/06/2015 7:16:00:01, 23/06/2015 7:16:00:02) you need only three threads since the request coming at 0.3 can be performed by the thread that server the first request (the one at 0), and so on (the request at time 0.4 can reuse thread used for the request that came at 0.1). Ten requests managed by three threads.
I recommend you (if you did not it already) to read Java Concurrency in practice (Task Execution is chapter 6); which is an excellent book on how to build concurrent application in Java.
From oracle documentation from Executors
public static ExecutorService newCachedThreadPool()
Creates a thread pool that creates new threads as needed, but will reuse previously constructed threads when they are available. These pools will typically improve the performance of programs that execute many short-lived asynchronous tasks.
Calls to execute will reuse previously constructed threads if available. If no existing thread is available, a new thread will be created and added to the pool. Threads that have not been used for sixty seconds are terminated and removed from the cache.
Thus, a pool that remains idle for long enough will not consume any resources. Note that pools with similar properties but different details (for example, timeout parameters) may be created using ThreadPoolExecutor constructors.
public static ExecutorService newFixedThreadPool(int nThreads)
Creates a thread pool that reuses a fixed number of threads operating off a shared unbounded queue. At any point, at most nThreads threads will be active processing tasks. If additional tasks are submitted when all threads are active, they will wait in the queue until a thread is available.
If any thread terminates due to a failure during execution prior to shutdown, a new one will take its place if needed to execute subsequent tasks. The threads in the pool will exist until it is explicitly shutdown.
#Giovanni is saying that you don' have to provide number of threads to newCachedThreadPool unlike newFixedThreadPool(), where you have to pass maximum cap on number of threads in ThreadPool.
But between these two, newFixedThreadPool() is preferred. newCachedThread Pool may cause leak and you may reach maximum number of available threads due to unbounded nature. Some people consider it as an evil.
Have a look at related SE question:
Why is an ExecutorService created via newCachedThreadPool evil?
What is the use of a Thread pool? Is there a good real world example?
A thread pool is a group of threads initially created that waits for jobs and executes them. The idea is to have the threads always existing, so that we won't have to pay overhead time for creating them every time. They are appropriate when we know there's a stream of jobs to process, even though there could be some time when there are no jobs.
Here's a nice diagram from Wikipedia:
Thread Pools from the Java Tutorials has a good overview:
Using worker threads minimizes the overhead due to thread creation. Thread objects use a significant amount of memory, and in a large-scale application, allocating and deallocating many thread objects creates a significant memory management overhead.
Thread pool is a pool of already created worker thread ready to do the job. It creates Thread and manage them. Instead of creating Thread and discarding them once task is done, thread-pool reuses threads in form of worker thread.
Why?
Because creation of Thread is time consuming process and it delays request processing. It also limits number of clients based upon how many thread per JVM is allowed, which is obviously a limited number.
Create fixed size thread pool using Executor framework -
Java 5 introduced a full feature built-in Thread Pool framework commonly known as Executor framework.
Creating fixed size thread pool using Java 5 Executor framework is pretty easy because of static factory methods provided by Executors class. All you need to do is define your task which you want to execute concurrently and than submit that task to ExecutorService.
From here, Thread pool will take care of how to execute that task; it can be executed by any free worker thread.
public class ThreadPoolExample {
public static void main(String args[]) {
ExecutorService service = Executors.newFixedThreadPool(10); //create 10 worker threads in Thread Pool
for (int i =0; i<100; i++){
service.submit(new Task(i)); //submit that to be done
}
service.shutdown();
}
}
final class Task implements Runnable {
private int taskId;
public Task(int id){
this.taskId = id;
}
#Override
public void run() {
System.out.println("Task ID : " + this.taskId +" performed by "
+ Thread.currentThread().getName());
}
}
Output:
Task ID : 0 performed by pool-1-thread-1
Task ID : 3 performed by pool-1-thread-4
Task ID : 2 performed by pool-1-thread-3
Task ID : 1 performed by pool-1-thread-2
Task ID : 5 performed by pool-1-thread-6
Task ID : 4 performed by pool-1-thread-5
*Output may vary from system to system
A simple Google search will result in a wealth of information regarding Java thread pools and thread pools in general.
Here are some helpful links:
http://docs.oracle.com/javase/tutorial/essential/concurrency/pools.html
http://en.wikipedia.org/wiki/Thread_pool_pattern
Thread Pools are useful only in a Server-client kind of situation where the number/occurrence of client requests cannot be determined/predicted.
In this scenario, creating a new Thread each time a client request is made has two dis-advantages:
1) Run time latency for thread creation:
Creation of a thread requires some time, thus the actual job does not start as soon as the request comes in. The client may notice a slight delay.
This criteria is crucial in interactive systems, where the client expects an immediate action.
2) Uncontrolled use of System Resources:
Threads consume system resources (memory etc.), thus the system may run out of resources in case there is an unprecedented flow of client requests.
Thread pools address the above concerns by:
1) Creating specified number of threads on server start-up instead of creating them during the run-time.
2) Limiting the number of threads that are running at any given time.
Note: The above is applicable for Thread Pools of Fixed Sizes.
You may assume Threads to be actual workers and Thread Pools to be group of workers.
You may create multiple groups for various reasons like priority, purpose, etc.
So, while one pool may be for general purpose tasks like background schedules, email broadcasting, etc. there might be a transaction processing pool to simultaneously process multiple transactions. In case of an Executor Service, I am sure you would not like to delay the transactional jobs to be completed after other non-critical activities like broadcasting confirmation emails or database maintenance activities are not completed.
You may segregate them into pools and maintain them independently.
That's a very simplistic answer without getting into technical jargons.
Regards,
KT
Already great answers are there to explain it but Lets understand it
with an example:
Problem without thread pool: Consider a web server application where each HTTP request is handled by a separate thread. If the application simply creates a new thread for every new HTTP request, and the system receives more requests than it can handle immediately, the application will suddenly stop responding to all requests when the overhead of all those threads exceed the capacity of the system.
Solution with thread pool: With a limit on the number of the threads that can be created, the application will not be servicing HTTP requests as quickly as they come in, but it will be servicing them as quickly as the system can sustain.
For more details(overhead of all the threads): Why is creating a Thread said to be expensive?