Geeks With Blogs
Greg Young Greg.ToString()

In .NET 1.x if you wanted to modify the stack size of a thread you created you would have to go through some pretty nasty code .. Here is a hint :)

[DllImport("kernel32.dll", SetLastError=true)]
static extern int CreateThread (ref SECURITY_ATTRIBUTES lpThreadAttributes,
int dwStackSize, ref int lpStartAddress, ref object lpParameter,
int dwCreationFlags, ref int lpThreadId)

In 2.0 a new overload has been added to the Thread class to support alterring your stack size directly through managed code http://msdn2.microsoft.com/en-US/library/5cykbwz4.aspx. There are a few interesting things about the documentation listed.

Unmentioned in the documentation is the fact that this method will only work in Windows XP or 2003. If you are in <= 2000 you will have to use another mechanism in order to change the stack size for your thread. Chris Brumme discusses it here http://blogs.msdn.com/cbrumme/archive/2003/04/15/51351.aspx. Basically what you have to do is use a tool included with visual studio called “editbin.exe” loacted in your visual studio\bin directory. It has a /stack option which will alter your .exe to change this option for all threads in your application.

The size being “optimal“ is another questionable point .. according to SQLServer documentation http://support.microsoft.com/kb/q160683/ 

Keep in mind that the amount of thread stack space will vary from application to application. If you specify a stack size that is too low for your application, SQL Server will report stack overflow errors. Unfortunately, there is no easy way to estimate the amount of stack space necessary. Therefore, it is recommended that the stack space not be set below 16K. Testing has shown that this amount should be adequate for most applications.

Another odd point about the documentation is that it tells you to not use the overload.

Avoid using this constructor overload. The default stack size used by the Thread(ThreadStart) constructor overload is the recommended stack size for threads. If a thread has memory problems, the most likely cause is programming error, such as infinite recursion.

I am not sure whether this is “Mort” documentation or if there is a further reason, but I am happy to guess. The “Einstein” documentation included with the Windows API says the following

It is best to choose as small a stack size as possible and commit the stack that is needed for the thread or fiber to run reliably. Every page that is reserved for the stack cannot be used for any other purpose.

This only thing that I can think of that might nullify this would be the cardinality of managed threads to OS threads. An OS thread with a very small stack size is much less likely to be reused than a thread with a standardized stack size.

I should probably add here that I am talking about a fringe condition, in general you should not be doing this type of thing, you should be using the thread pool, but there are some circumstances when it is better not to.

What to do?

 

Posted on Tuesday, May 2, 2006 9:17 AM Under the covers | Back to top


Comments on this post: 2.0 Specify Thread Stack Size

# re: 2.0 Specify Thread Stack Size
Requesting Gravatar...
I have also reasoned about the Stacksize of managed threads. My tests did show that at about 39-40000 nested calls a StackOverFlowException is thrown. The size should not matter on 64 bit machines where we have virtually endless address space but on 32-bit machines and having every unmanaged thread as default 1MB stack size we can create (only) 2000 unmanaged thread before we run out of memory. What is even more interesting that these reliability features regard StackOverFlowException do not work in normal .NET applications:

http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=805acca3-6d11-479e-b700-18eba204422f

Unfortunately the MSDN does not clearly say when these features can be used and when not.

Yours,
Alois Kraus
Left by Alois Kraus on May 03, 2006 2:14 PM

# re: 2.0 Specify Thread Stack Size
Requesting Gravatar...
It depends on how many parameters / variables the function has as all of those items take up stack.

Of course, 2000 managed threads is quite alot, I would start to wonder about one's design in 99% of cases .. I think my largest set has actually been about 200 (queued workers running long I/O tasks) :)

Left by Greg Young on May 03, 2006 3:06 PM

Your comment:
 (will show your gravatar)


Copyright © Greg Young | Powered by: GeeksWithBlogs.net | Join free