Attila Szegedi a écrit : > If you wish to do it in a reasonably non-messy way, you'd need to > figure out how to chunk your task into pieces that don't block a > thread (or better said, only would block at their last operation), > replace the blocking operations with asynchronous non-blocking > equivalents and have some sort of a central scheduler component > schedule the next chunk when a completion notification for the async > operation comes in. That way, you'll end up with best multi-CPU > utilization. This is of course no trivial task, and is actually a sort > of cooperative concurrency where the concurrency aspects are > explicitly visible in your system architecture (contrary to preemptive > thread scheduling which tends to be less visible). Also, in order to > not need to chunk up the source code for the task's algorithm > lexically, you'll want a language that supports closures and > generators, and a platform that can give you asynchronous I/O with > completion notifications. > > An impressive example of such a framework is Microsoft's CCR > (Concurrency and Coordination Runtime). CCR allows you to write > programs in a way as to maximally utilize the CPU with minimal number > of threads, by avoiding threads from blocking. Various syntactical > goodies in C# (most notably closures, generators, and delegates) allow > you to express your code fairly cleanly, in a single method if need be > - you write your algorithm in a generator method so that it yields > closures in a sequence, each closure performing one non-blocking unit > of work, and CCR will have them scheduled in sequence - the next > closure gets scheduled sometime after the completion notification for > the previous one comes in; since generators preserve state across > yields, you can have local variables, and yields nested in loops and > whatnot. > I haven't read anything about CCR, but it seems a bit weird to use generator here. Generator tranform local variables to fields see section 10.14.4 of C# 3.0 spec, so it transform local vars to variables that will require synchronisation ??
I think i prefer to use Fork/join framework. > Of course, it's a CLR technology, and I really wish an equivalent > existed for JVM. Such an effort on JVM would at present be hindered by > incomplete support for async IO in the java.nio.* package (i.e. no > async file IO) as well as lack of closures and generators in the Java > language (although you could turn to Scala for that). > async io in Java => see NIO 2, i think it should be included in the JDK. http://jcp.org/en/jsr/detail?id=203 and prototype here: http://hg.openjdk.java.net/jdk7/nio2/jdk/ > Attila. > Rémi --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
