[Mono-dev] [PATCH] System.Threading.Parallel

Andreas Färber andreas.faerber at web.de
Sun Dec 23 12:17:20 EST 2007

Am 21.12.2007 um 15:23 schrieb Marek Safar:

> I would not add this to corlib as it may cause problems later when MS
> introduces better "Parallel" library support.
>> To completely support the "Parallel" Library, in addition the
>> ParallelEnvironment class would need to be implemented inside corlib.
>> But with Microsoft not having supported it, relying on its presence
>> would keep users from deploying this assembly to .NET. The proposed
>> implementation therefore uses conditional sections where
>> ParallelEnvironment should theoretically be used.

It seems Microsoft is using one or multiple instances of  
System.Concurrency.TaskManager to control the number of concurrent  
threads. ParallelEnvironment.MaxThreads roughly corresponds to the  
global TaskManager's .MaxConcurrentThreads.

>> Adding that class to corlib might require a new icall for
>> ParallelEnvironment,RecommendedMaxThreads (to discover the number of
>> processors/cores)

I found that System.Environment.ProcessorCount already returns the  
number of processors or cores. Therefore no icall would be required,  
the scaling could be done in managed code.

So given that the two do not conflict I see three options:
- add System.Threading.Parallel.ParallelEnvironment to corlib and  
conditionally depend on its presence (similar to now), or
- add a public Mono.Threading.Parallel.ParallelEnvironment to our  
System.Threading.Parallel.dll and (conditionally) use this one  
instead, or
- add a (System|Mono).Threading.Parallel.ParallelEnvironment in a  
separate, Mono-specific assembly

Without the class in corlib, any source/IL code conformant to the  
standard would break.
With the class correctly in corlib, code using it cannot be deployed  
to non-conforming Microsoft .NET.
With the class in a Mono-specific assembly, code using this class is  
not standard-conformant.
With a Mono-specific class in SPT, code using this class is no longer  
With a Mono-specific class in a Mono-specific assembly, runtime  
behavior is undefined for any other SPT implementation.

I'd favor having it in corlib for completeness and providing a custom  
frontend in a Mono assembly; that could then check for Parallel  
support via Reflection and set/get the value either there or locally.  
Mono's SPT could then rely on its deployable companion assembly as an  
Adapter to work on both Mono and any other runtime.


More information about the Mono-devel-list mailing list