It's difficult to be sure what's happening without really examining the application. I suspect, though, that this has something to do with garbage collection. I take it you are using Poly/ML 5.5 and not an earlier version? Each thread does have its own segment to allocate in but getting another segment does not involve any other thread. When the memory runs out and a GC is needed all the threads are stopped. GC is run as a completely separate phase and isn't overlapped with any ML execution. Since version 5.5. the GC has been parallelised unless explicitly overridden with --gcthreads.
There are ways to get information from the Poly/ML run-time system to help you understand what is happening. The --debug option causes various parts of the RTS to print information. See poly --help for a list of the options. The PolyML.Statistics will get information out about the current process and can also be used to get information about another poly process. Magnus Stenqvist, a student of Tjark Weber, wrote some code to view the statistics of another process. I haven't tried it myself yet but it's here https://bitbucket.org/manne/poly-ml-system-monitor if you want to try it.
David
On 08/04/2013 19:21, Michael Bradley wrote:
Dear all, I am experiencing inefficiency while using the Futures library within PolyML. Parallel threads are being forced to 'sleep' for several seconds at a time for no clear reason, and I suspect it may be due to memory management between multiple threads. The test