Root / Assembly / ARCCore / AREnumType / DocumentationOnlyEnum / ARConcepts / _Member / SingleThreadedCode



DescriptionSome practical choices have been made in AgoRapide which requires object access to be done in a single-threaded manner, or within a locking context (using for instance -ReaderWriterLockSlim-).

Examples are like
1) In objects like PRich, using System.Collections.Dictionary instead of System.Collections.Concurrent.ConcurrentDictionary due to memory concerns and (when building a hierchical object model) due to the inherent dangers for bugs that a multi-threaded model would bring).

Note hints in the documentation for how to write thread safe applications, for instance documentation for OutsideLocalReceiver. Also note objects like PConcurrent which may be used when you definitely need multi-threaded access.

The inbuilt distributive possibilities in AgoRapide is supposed to be a good fit with this restriction. If you need more processing power than what a single main-thread can give you, then it is very easy to distribute load over multiple ARNodeType nodes. Each of these nodes should anyway only have to do a simple easy to understand task, and then a single main thread should be no real restriction.

Note that where relevant AgoRapide does of course make extensive use of multithreaded code, ascynchronous code (async / await) and so on.

3 items

Generated 2020-10-13 11:11:01.189 UTC