Databases
StackOverflow2013
Postsdbo
POCross AppDomain Thread Pool W/O Context Switching
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POCross AppDomain Thread Pool W/O Context Switching
    primarykey
    data
    text
    <p>Our application is heavily CPU bound to process billions of tuples of data as fast as possible. It uses multi-cores and soon moving to distributed in the cloud. </p> <p>So the goal is to using the CPU absolutely as efficiently as possible. This question is about how to maintain that high level of performance will allows plugs to loaded/unloaded dynamically at run time.</p> <p>Please understand that while it's easy to communicate across AppDomains, none of the "easy" ways will meet the performance requirements above. So this questions discusses the reasons that the common techniques are too slow and further requirement plus specific questions of our ideas to solve.</p> <p>To achieve the performance, the application has been designed to communicate among components via "message passing" which means that we have a user mode task scheduler to keep those threads busy without ever (except when necessary) relinquishing any time slices or context switches to the operating system.</p> <p>The ONLY way to unload DLLs in .NET is via AppDomains. However, to maintain the high level of performance described above it means that the thread pool (we have our own home-grown thread pool) must be able to perform tasks in various different AppDomains.</p> <p>More specifically, it will be terrible performance to have separate threads for each of dozens of AppDomains that then compete for CPU. More threads than cores for CPU bound work will kill performance as the operating systems spends tremendous time context switching among threads.</p> <p>There seems after preliminary research zero efficient way for our own thread pool to cross into other AppDomain with any kind of decent performance. Remoting or serializing are both impossibly slow even with zero arguments to methods. </p> <p>Please note that this is not about data sharing. We don't want to use the thread calls into different AppDomain to passing data. Instead, we expect to share data among AppDomains via sockets and memory mapped files for top flight performance just like proper Interprocess Communication. So this question only relates to get threads working across AppDomains.</p> <p>The following link here on Stackoverflow which is over 2 years old hints at capitalizing on the built-in thread pool in the CLR for .Net which states that it crosses other AppDomains to do tasks. MS documentation also verifies that the CLR thread pool operates across all AppDomains.</p> <p><a href="https://stackoverflow.com/questions/1751294/net-how-to-create-a-custom-threadpool-shared-across-all-the-appdomain-of-a-proc">.Net How to create a custom ThreadPool shared across all the AppDomain of a process?</a></p> <p>Still after reading documentation, how to use the built-in thread pool across AppDomain while NEVER allowing any context switches when crossing AppDomains?</p> <p>So the design goal is how to rotate the threads (one per core) to frequently check the "run queue" of tasks in each AppDomain to see if there is work to do there and then move to the next AppDomain? And so on, looping through each AppDomains scheduler? How to do that w/o waiting any context switching overhead or remoting or marshalling?</p> <p>Note, of course, we'll have some cleverness into which AppDomains are assigned to each threads to avoid L1 cache misses and such to avoid hardware bottlenecks.</p> <p>Also another idea that we wonder about is writing our own custom CLR host. It appears that the C++ API allows implementing our own thread pool. Does anyone know if that will allow for the above capabilities? If so, is that the only way to do it through unmanaged code? </p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USCommunity
    1. USWayne
    plurals
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. POCross AppDomain Thread Pool W/O Context Switching
      1. This table or related slice is empty.
      1. VTUpMod
    1. COHave you thought about instead of 'pulling' within the appdomains for work, making the appdomains push to a centralized location? (welcome engine)
      singulars
      1. POCross AppDomain Thread Pool W/O Context Switching
      1. USPolity
    2. CODo plugins need to be unloaded immediately? Would it be possible to just start a new app domain after reaching a certain threshold?
      singulars
      1. POCross AppDomain Thread Pool W/O Context Switching
      1. USSneal
    3. COI assume you tried using AppDomain.DoCallback and that proved to be to slow?
      singulars
      1. POCross AppDomain Thread Pool W/O Context Switching
      1. USPhil Wright
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload