On 07/26/2011 01:45 PM, Jafar Al-Gharaibeh wrote: > Steve, > > Here is a follow up on this. I happened to be running Windows 7 Ultimate > 32-bit at the moment, and because it is > always fun to test under Windows, I went a head and ran you little program. > Here are the results:- ... > c:\projetcs>ar 10 > fib(10)=55 > > c:\projetcs>ar 11 > System error at line 24 in ar.icn > cannot create thread > > You can see that all went well up to fib(10). At 11, my system runs out of > resources quickly because the number of > (co-exp) threads involved seems to be more than what the system can handle in > its current state (I'm multi-tasking.. and > firefox is running with 10s of tabs :) open ). To get a better handle on > this, I tried the little toy > "unicon\tests\thread\sum.icn" because I can control (and know) how many > threads are running. With Windows task manager > open, I ran "sum" several times with different arguments. The argument is the > number of threads to be created. I was > able to run "sum" with up to 225 threads. Adding one more thread was enough > to get Windows "fed up" with my test and > start throwing several error messages, including the one above and also the > ones you reported earlier which are actually > symptoms of the above error. I can see in Windows Task Manager that the > number of threads jumps roughly by how many > threads "sum" creates. The total number of threads in the system seems to gap > between 900 and 1000. Insufficient memory, > uninitialized mutexes, threads are all parts of the error messages I get.
This sounds good. I suspect a problem in the 2.6.18 kernel/libraries used by CentOS 5.6 is limiting the runs I do (the machine as 12 cores and 16GB of ram plus 16GB of swap, and claims to support 10's of thousands of threads). Yet I see the error at ar 12. I'd expect to get a little farther than that with those resources, especially since my little laptop (4 cores+hyperthreading, 6GB of ram, running the 2.6.38 kernel Ubuntu 11) gets through ar 14 with no error [I don't have to patience to sit through ar 15...]. If there were a way to query Unicon for the number of threads/co-expressions, that might be useful. I could run that in a separate thread and watch the growth. (The same thread could monitor string/heap/etc memory consumption.) Thanks for checking this!! I'll report back in a month or so after upgrading to CentOS 6... [I *think*, without doing a lot of it, that ar uses approximately 2^N threads, where N is the argument. so ar 10 uses ~1024 threads, ar 12 is at 4096, and ar 14 (laptop still runs) 16384.] Come to think of it, there ought be to be some co-expressions completing and so finishing with their threads as the program runs. At most N threads should be 'active' at any one time since these are plain-old non-concurrent co-expressions. This makes me think that the co-expressions aren't being freed when they complete [and not garbage collected, either] and so the threads aren't released. This wouldn't explain why my laptop beats my big machine, but might help explain why things don't run longer in general. Is there any way to check this? -- Steve Wampler -- [email protected] The gods that smiled on your birth are now laughing out loud. ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ Unicon-group mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/unicon-group
