You could use events to sync. Like this: private static ManualResetEvent resetEvent = new ManualResetEvent(false); public static void Main() { ThreadPool.QueueUserWorkItem(arg => DoWork()); resetEvent.WaitOne(); } public static void DoWork() { Thread.Sleep(5000); resetEvent.Set(); } If you don’t want to embed event set into your method, you could do something like this: var resetEvent = new ManualResetEvent(false); … Read more
The best practice is not to reuse the pool (what would be the use of pooling, if you keep creating new pools?). If you want to be sure you “time” the batches together, I’d suggest using when_all on futures: Live On Coliru #define BOOST_THREAD_PROVIDES_FUTURE_WHEN_ALL_WHEN_ANY #include <iostream> #include <boost/bind.hpp> #include <boost/asio.hpp> #include <boost/thread.hpp> uint64_t foo(uint64_t begin) … Read more
Two ways: Have a bean implement ApplicationListener<ContextClosedEvent>. onApplicationEvent() will get called before the context and all the beans are destroyed. Have a bean implement Lifecycle or SmartLifecycle. stop() will get called before the context and all the beans are destroyed. Either way you can shut down the task stuff before the bean destroying mechanism takes … Read more
You’re closing over the loop variable, which gives you an unexpected result. Try this instead: foreach(string item in Items) { string item2 = item; Console.WriteLine(“Adding {0} to ThreadPool”, item2); ThreadPool.QueueUserWorkItem ( delegate { Load(item2, this.progCall, this.compCall); } ); numThreads++; Thread.Sleep(100);//Remove this line } References Closing over the Loop Variable in C# Closing over the loop … Read more
Without the threads, your code is being executed on the FX Application Thread. This is the thread that is (effectively) responsible for rendering the UI to the screen and for processing user input. If you execute a long-running task on this thread, then you prevent any of the normal functionality of the FX Application Thread … Read more
Have a look at below API in ThreadPoolExecutor public void setCorePoolSize(int corePoolSize) Sets the core number of threads. This overrides any value set in the constructor. If the new value is smaller than the current value, excess existing threads will be terminated when they next become idle. If larger, new threads will, if needed, be … Read more
If you have CPU bound tasks, as you increase the number of threads you get increasing overhead and slower performances. Note: having more threads than waiting tasks is just a waste of resources, but may not slow down the tasks so much. I would use a multiple (e.g. 1 or 2) of the number of … Read more
I used to work on an app with long running threads. We do this at shutdown, BlockingQueue<Runnable> queue = threadPool.getQueue(); List<Runnable> list = new ArrayList<Runnable>(); int tasks = queue.drainTo(list); The list is saved to a file. On startup, the list is added back to the pool so we don’t lose any jobs.
I know an answer has been accepted, if you need this right now, and you can’t be bothered to write your own thread pool, you could try using boost asio io_service with a concurrency hint (i.e. how many threads it should run) and then post() stuff to this io_service… just an idea..
The set of ThreadLocal instances associated with a thread are held in private members of each Thread. Your only chance to enumerate these is to do some reflection on the Thread; this way, you can override the access restrictions on the thread’s fields. Once you can get the set of ThreadLocal, you could copy in … Read more