Hi Stefan, Interesting points you have raised.
- This threading model needs to support lazy execution - These dataflow threads suspend on data availability - These threads need to support data synchronization from other threads - As Ulf Wiger pointed out: if the threads are heavy this will influence the programmer to code in such a way as to limit the amounts of threads spawned -- so when a problem requires the structure of a program to have 100 000s of threads, the programmer will avoid such an approach. As a side note all these 100 000 should be simultaneous and active. The below is a brief summary of the types of threads needed. It is all documented in CTM. Thread scheduling: - Time slices -- all ready threads need to be put into a queue, once a thread is pulled out it is put back into the queue - creating a round robin type scheduling - This guarantees processor time spread out evenly. -- each thread executes as much as it can - given data availability -- then pre-empting the thread by putting it back queue once its time limit has been reached --- pre-empting ---- way 1: count computation steps and give same number to each thread ----- advantage: it is deterministic ---- way 2: use hardware timer and allocate each thread an even amount of time ----- advantage: more efficient Priority levels: - If a high priority thread spawns, it cannot under any circumstance starve other threads - as this will kill dataflow -- there are three queues low, medium and high. -- child threads have same priority level -- if child thread is put into a medium queue then bumped up to the same level as parent high priority this can cause difficult timing bugs -- therefore a thread should never have lower than parent priority level Cooperative and competitive concurrency: - Threads are meant to be cooperative, these are meant for applications executing in an environment where all parts trust each other (dataflow). They also need to manage their own priority levels. - competitive processes don't care about global performance and only care about their own performance. It is usually managed by the OS. - mozart supports competitive threads but only inter node communication and the remote module. So these are some of the characteristics of dataflow threads. Is it possible to implement this without thread starvation, with lazy execution and spawning 100 000 threads on the JVM? Otherwise the new JVM mozart oz will be step down. As the goal is to have a platform that is used to test new language features, is it not best to run with a model that can achieve the needed requirements? Kind regards Stewart On Tue, Oct 11, 2011 at 9:45 PM, Stefan Marr <[email protected]> wrote: > Hi: > > On 11 Oct 2011, at 14:51, stewart mackenzie wrote: > >> Though I am struggling to find anything that allows me to spawn 100 >> 000 threads and kill them off in under a second. >> To me ExecutorService is just an simple abstraction away from raw java >> threads. >> >> Could you point me to anything that allows this kind mass thread >> spawn/kill behavior? > > First, I have the feeling you do not want to talk about threads. > You are probably more looking for something with a much more fine-grained > notion. > Perhaps 'tasks', perhaps co-routines. > > And then it really depends on what you actually want to do. > I do not know enough about your execution model, but your question sounds > like you want to proof that a plain sequential coroutine implementation has > less overhead than one that actually is executed on a thread pool. > Sure, it has overhead to put something on a queue, and it has overhead to > synchronize. > But, whether that is something to worry about really depends on what your > 100000 tasks are actually doing. > > It is likely that approaches like work-stealing, as it is used for the > Fork/Join framework of JDK7, cater for such things. Here the synchronization > overhead is minimized and load is balanced between your cores in near-optimal > fashion. (That is for problems that have a recursive structure.) > http://download.oracle.com/javase/tutorial/essential/concurrency/forkjoin.html > > However, what I remember of Mozart/Oz are the data flow variables. > And projects like StreamIt, or even X10 (to stay a bit more in the field if > fork/join like languages) use compiler mechanisms to coarsen up the > granularity of parallel computation. > There is conceptual overhead, and there is always the > communication/synchronization cost. > But well, if you are interested in these kind of mechanism, then you will > actually end up using coarse-grained threads again ;) > > Just in case it helps, here another list of keywords you might be interested > in: > There is Cilk, and Intel's TBB. Intel released Cilk+ and its libraries as > open source, I think. > That could also be an interesting starting point when the JVM is ruled out. > > Best regards > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > _________________________________________________________________________________ > mozart-hackers mailing list > [email protected] > http://www.mozart-oz.org/mailman/listinfo/mozart-hackers > _________________________________________________________________________________ mozart-hackers mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-hackers
