[Mono-bugs] [Bug 566057] New: SetMaxThreadCount does not allow you to set a limit lower than its default

bugzilla_noreply at novell.com bugzilla_noreply at novell.com
Fri Dec 18 12:35:42 EST 2009


http://bugzilla.novell.com/show_bug.cgi?id=566057

http://bugzilla.novell.com/show_bug.cgi?id=566057#c0


           Summary: SetMaxThreadCount does not allow you to set a limit
                    lower than its default
    Classification: Mono
           Product: Mono: Class Libraries
           Version: 2.4.x
          Platform: i686
        OS/Version: RHEL 4
            Status: NEW
          Severity: Critical
          Priority: P5 - None
         Component: System
        AssignedTo: mono-bugs at lists.ximian.com
        ReportedBy: dbialac at gmail.com
         QAContact: mono-bugs at lists.ximian.com
          Found By: ---
           Blocker: ---


User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_2; en-us)
AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9

According to the MSDN documentation, SetMaxThreadCount should allow me to set
it to a number no lower than the number of CPUs on the system I am on. 
Quoting:

        You cannot set the number of worker threads or the number of I/O
completion
        threads to a number smaller than the number of processors in the
computer.

        If the common language runtime is hosted, for example by Internet
Information
        Services (IIS) or SQL Server, the host can limit or prevent changes to
the thread pool size.

In my case, I am running a stand-alone process (not hosted by mod_mono) so this
constraint does not apply.  With this in mind, I try to set the limit to 16 (2x
per CPU on an 8-cpu virtual server of which I only have 1 CPU) using this code
snippet:

ThreadCount.GetMaxThreads( out worker, out async );
Console.WriteLine( "Worker: " + worker + ", Async: " + async );
ThreadCount.SetMaxThreads( 16, 16 );
int worker;
int async;
ThreadCount.GetMaxThreads( out worker, out async );
Console.WriteLine( "Worker: " + worker + ", Async: " + async );

The output of this is:
Worker: 100, Async: 100
Worker: 100, Async: 100

On a similar server running 2.6.0, the output is:
Worker: 140, Async: 140
Worker: 140, Async: 140

In the mono irc channel we briefly discussed this and I was told, "You don't
want to lower the defaults because of problems that could arise."  However,
when virtualizing with openvz, this is not the case.  Openvz reports the CPU
hardware that the main system has and mono makes decisions based on this.  This
in turn causes the resources that mono wants to use to frequently exceed the
resources actually available to it under the virtualized machine.  Though it
can be argued that openvz should report resources /proc according to what it
provides the VM, it can also be argued that mono needs to be flexible enough to
support these kinds of circumstances and further that the function needs to
operate as described in the MSDN .Net documentation.

Reproducible: Always

Steps to Reproduce:
1.Run the code snippet in the 'Details' section
2.
3.
Actual Results:  
The MaxThreadCount is unchanged.

Expected Results:  
MaxThreadCount should be altered to match the provided parameters so long as it
stays in the confines described in the .Net documentation.

Not relevant to the bug, but I want to say overall kudos with the Mono project.
 I really like what you've created here.

-- 
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the mono-bugs mailing list