 | DefaultThreadPoolService Class |
Inheritance HierarchySanteDB.Core.Services.ImplDefaultThreadPoolService
SanteDB.DisconnectedClient.ThreadingSanteDBThreadPool
Namespace: SanteDB.Core.Services.Impl
Assembly: SanteDB.Core.Api (in SanteDB.Core.Api.dll) Version: 2.2.1
SyntaxThe DefaultThreadPoolService type exposes the following members.
Constructors| Name | Description | |
|---|---|---|
 | DefaultThreadPoolService |
Creates a new instance of the wait thread pool
|
Properties| Name | Description | |
|---|---|---|
 | ServiceName |
Gets the service name
|
Methods| Name | Description | |
|---|---|---|
| Dispose |
Dispose the object
|
| Equals | Determines whether the specified object is equal to the current object. (Inherited from Object.) |
 | Finalize | Allows an object to try to free resources and perform other cleanup operations before it is reclaimed by garbage collection. (Inherited from Object.) |
| GetHashCode | Serves as the default hash function. (Inherited from Object.) |
| GetType | Gets the Type of the current instance. (Inherited from Object.) |
| GetWorkerStatus |
Get worker status
|
| MemberwiseClone | Creates a shallow copy of the current Object. (Inherited from Object.) |
| QueueUserWorkItem(ActionObject) |
Queue a work item to be completed
|
| QueueUserWorkItemTParm(ActionTParm, TParm) |
Queue a user work item with the specified parameters
|
| ToString | Returns a string that represents the current object. (Inherited from Object.) |
Fields| Name | Description | |
|---|---|---|
  | MAX_CONCURRENCY |
Maximum concurrency for the thread pool
|
Extension Methods| Name | Description | |
|---|---|---|
 | ConvertTReturn |
The purpose of this method is to convert object me to TReturn. Why?
Because if you have an instance of Act that actually needs to be a SubstanceAdministration we can't just cast
so we have to copy.
(Defined by ExtensionMethods.) |
| GetInstanceOfTDomain |
Gets an instance of TDomain from me
(Defined by ModelExtensions.) |
RemarksMany SanteDB jobs use threads to perform background tasks such as refreshes, matching, job execution, etc. Because we don't want uncontrolled explosion of threads, we use a thread pool in order to control the number of active threads which are being used.
Implementers may choose to register a IThreadPoolService which uses the .NET ThreadPool (see: NetThreadPoolService), or they can choose to use this separate thread pool service. There are several advantages to using the SanteDB thread pool rather than the .NET thread pool including:
- The default .NET thread pool can bounce work between threads when the thread enters a wait state, this can cause issues with the REDIS connection multiplexer
- SanteDB plugins may use PLINQ or other TPL libraries which require using .NET thread pool - and we don't want longer running processess consuming those threads
- Implementers may wish to have more control over how the Thread pool uses resources
This thread pool works by spinning up a pool of threads which wait for QueueUserWorkItem(ActionObject) which initiates (or queues) a request to perform background work. When an available thread in the pool can execute the task, the task will be run and the thread will work on the next work item.
If the thread pool needs additional threads (i.e. there are a lot of items in the backlog) it will spin up new reserved threads at a rate of number of CPUs on the machine. This continues until the environment variable SDB_MAX_THREADS_PER_CPU is hit.
Conversely, if the thread pool threads remain idle for too long (1 minute) they are destroyed and removed from the thread pool. This ensures over-threading is not done on the host machine.
See Also