100 threads then robot code gets terminated

[shuhao]

If i spawn 100 threads, even though only 2 is active at all times, the robot code get terminated.

Why is this happening? And anyone know what the work around is?

[RufflesRidge]

Originally Posted by shuhao

And anyone know what the work around is?

Don't spawn 100 threads?

[Zholl]

Originally Posted by RufflesRidge

Don't spawn 100 threads?

I would have to agree here. Granted, I don't have much experience in Java, but my experience with other languages has been that if you have too many simultaneous threads of execution, the program slows down until the whole thing times out and crashes

[Chiller]

Originally Posted by Zholl

I would have to agree here. Granted, I don't have much experience in Java, but my experience with other languages has been that if you have too many simultaneous threads of execution, the program slows down until the whole thing times out and crashes

Yes that would even happen on non cRio applications such as a game on a computer... Why would you want 100 threads??

[shuhao]

I don't have 100 active threads. I just spawned that many over Time. The Max active thread count I have is 2..

[derekwhite]

What output is reported? Can you try to print out the amount of free Java heap occasionally (Runtime.getRuntime().freeMemory())?

You can also check the number of currently executing threads (including those that are waiting for something), by calling Thread.activeCount().

[shuhao]

Ill do the memory count tomorrow. Active thread is 2, as I've been trying to say...

[wireties]

The operating system on the cRIO is vxWorks. The algorithm to select the next task/thread to run is constant order, in other words it doesn't care how many threads/tasks exist. My guess is that you are exhausting main memory somehow. What do all your threads do? It is hard to see the tulity of 100 threads on a FIRST robot.


HTH

[shuhao]

.. again, the 100 threads are NOT concurrent. It is spawned during the life time of the operation ...

[Greg McKaskle]

I'm not that familiar with the Java VM implementation, but I assume it is stack based, like C and C++. Each thread is given its own stack along with other allocations for managing the thread resources. On some OSes that is not too big initially, but they have lots of VM room to grow into. On other OSes, they preallocate lots of stack for each thread. If your stack was 1MByte, then you would run the VM out of memory way before 100.

LabVIEW works around this by having a thread pool and generating its code to not be stack based, but be frame based. That allows it to have hundreds of parallel tasks without having hundreds of threads. But if your OS can handle hundreds of threads, you change a config and tell it to use that many. By default, it has four per processor per priority which are allocated as priorities are added.

On the DS, flip to the new Charts page and run your program. On the far right side are three numbers for free disk, RAM, and largest RAM. If the RAM is constantly dropping, you are hoarding or leaking memory. If the crash takes place about the time your RAM gets low, and especially when the Largest Block gets too small, then that explains it, right?

Greg McKaskle

[Chiller]

Originally Posted by shuhao

.. again, the 100 threads are NOT concurrent. It is spawned during the life time of the operation ...

Then kill the old threads!