SmartThreadPool icon indicating copy to clipboard operation
SmartThreadPool copied to clipboard

Race condition in SmartThreadPool causes not processing tasks

Open jeernest opened this issue 4 years ago • 4 comments

Hi,

I found an issue in using groups and I would like to check if it is known issue or not.

steps to reproduce:

  1. Start a ThreadPool with a WorkGroup - set MinThreads = 0, MaxThreads =1, IdleTimeout = 60 seconds
  2. Send a task to WorkItemGroup every 60 seconds
  3. after some time, tasks stop to process

Here is what happens: Thread#1 [STP Worker thread] timeouts, because it has empty queue for 60 seconds and starts terminating (there's still some work to do after the timeout check and before the thread is freed) In meantime Thread#2 [new thread] enqueues a task to the WorkItemGroup, Thread#2 WorkItemGroup enqueues a task to SmartThreadPool expecting that STP withdraw the task, Thread#2 STP enqueues a task and doesn't start a thread, because there's one already running (it doesn't know that it's terminating) Thread#1 [STP Worker thread] finishes termination and removes itself from STP Thread#3 [new thread] [Receiver] enqueues a task to Work Items Group Thread#3 WorkItemGroup doesn't do anything, because it thinks that STP has already enough tasks in queue

since then the STP has no running thread and all new tasks are enqueued to the WorkItemGroup and the queue is growing and never processed

jeernest avatar Jan 13 '21 17:01 jeernest

Have you found a solution for this? I think I am experiencing something similar

MichelZ avatar May 05 '21 05:05 MichelZ

Unfortuntely, no. We stopped using work item groups and everything started to work.

jeernest avatar May 05 '21 10:05 jeernest

Which versions are affected by this issue?

jirkapok avatar Aug 18 '21 11:08 jirkapok

Which versions are affected by this issue?

As far as I remember it was 2.0

jeernest avatar Aug 18 '21 12:08 jeernest