Home› AMX User Forum› Duet/Cafe Duet

How many Threads is too many?

JasonSJasonS Posts: 229
in Duet/Cafe Duet
In ongoing discussions with AMX there seems to be an issue if to many THreads are created in Duet. But, there does not seem to be a clear picture of how many is too many. Using Thread.activeCount() it seems that there are approximately 18 threads running with a single module running. I am writing a program that will be opening many ip connections concurrently, with each connection running in its own Thread. Anybody have any thoughts/experience on this topic?

Comments

  • mighemighe Posts: 39
    In the older JVM version only a thread at once could run, so there were no real parallelism for cpu based task, but we can still use effectively them for IO based task, like connections. I've not tried to run the test in the 3.60 firmware JVM.

    For the number of thread, I've never had any problem: I use up to 2 thread per connection and some of our running systems have more than 40 threads living at the same time in the same module.

    I've never tried to stress test a controller to see how many IO threads can be spawn safely, but in my opinion you will not have any problems.
  • JasonSJasonS Posts: 229
    Thank you for the information, that is great news, I was thinking about doing 25 connections concurrently so it sounds like that will work.
  • amclainamclain Posts: 41
    One of my friends stress tested a Duet module on an NI-2000 about three years ago and it maxed out around 64 threads if I remember correctly. There’s an exception that’s thrown when you hit the limit and the Java VM shuts down (crashes). I don’t know if the thread count has been increased in the NI-x100 series.

    If you have to deal with a high number of IP (or other blocking) connections, making some of them non-persistent can reduce the system resources that are used. For example, PJLink projectors only respond to queries, so after I receive the response to a query I close the socket. The projector can’t send any data I didn’t ask for, so I won’t miss anything by closing the connection, and now those resources are freed up to go query the next device. The “command” design pattern is helpful for this kind of thing.
Sign In or Register to comment.