[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
standard-conformant.
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.
Andreas
More information about the Mono-devel-list
mailing list