Yes, one of the reasons to use Java was for threading. Other reasons include an improved security model, the package system, being able to manipulate the byte codes etc.
I find threading under Java to be a little easier than under C++ if only because getting a C++ threading package working under different platforms can be tricky. For example, SystemC-2.0.1 had their own threadin package that just did not work under Cygwin, though it worked fine everywhere else. SystemC-2.1 solves this problem by allowing the user to choose pthreads, which works well under Cygwin. However, personally, I find the Java threading primitives to be, well, primitive. Looking at Doug Lea's work and the new threading features in Java 1.5 might be of interest. I think programming in threads using the Java primitives is tricky, and even Sun has had problems with Swing and the Swing Event thread. Initially, I thought threads were going to be a real win, much like Object Oriented design. However, after using threads for awhile, I've realized that like OO design, it is very easy to create unworkable code. Below are some Java thread resources. * The Java Tutorial has some fundamental info about Threads http://java.sun.com/docs/books/tutorial/essential/threads/index.html * Concurrent Programming in Java, by Doug Lea. http://java.sun.com/docs/books/cp/index.html Online supplement: http://gee.cs.oswego.edu/dl/cpj/index.html * Doug Lea's util.concurrent classes http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html * J2SE 1.5 includes much of util.concurrent: http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/package-summary.html http://gee.cs.oswego.edu/dl/concurrency-interest/ It would be interesting to reimplement portions of Ptolemy II using the Java 1.5 java.util.concurrent classes. We have no plans to do this. > What I was referring to was, are there any specific coding styles > that allows the consideration of both thread models, or avoiding > any special thread calls, synchronizations etc. I believe the > only place to figure this out would be in the list of classes you > mentioned below? For Ptolemy II, the best place to start is Volume II of the design doc, and then have a look at the code. BTW - I might be wrong about how independent Ptolemy II is from cooperative vs preemptive scheduling. However, I believe we have addressed the differences. For example, it could be that the schedule of PN actors that are fired will differ between the two schedulers, but that the overall result will not be different. Perhaps someone else has more info about this. _Christopher -------- > Yes, Ptolemy's code accomodates both cooperative and preemptive thread > models by design. We run the test suite under both Solaris and > Windows, which have different native threading models. Ptolemy > domains are usually deterministic even when run on different > platforms. > > The fact that scheduling is platform dependent under Java is (IMHO) > one of Java's failings. So much for write once, run everywhere. > I was under the impression that one of the reasons for moving to Java for P tolemy II was to take advantage of the thread package in Java and to allow f or platform-independence. > I'm not sure I understand the question? What I was referring to was, are there any specific coding styles that allo ws the consideration of both thread models, or avoiding any special thread c alls, synchronizations etc. I believe the only place to figure this out wou ld be in the list of classes you mentioned below? > ptolemy.actor.Manager uses > ptolemy.kernel.util.PtolemyThread > > ptolemy.actor.process.ProcessThread uses > ptolemy.kernel.util.PtolemyThread > > ptolemy.actor.process.ProcessDirector uses > ptolemy.actor.process.ProcessThread > > ptolemy.actor.process.CompositeProcessDirector extends > ptolemy.actor.process.ProcessThread > > CSPDirector, DDEDirector and PNDirector all extend > ptolemy.actor.process.CompositeProcessDirector.java > > You could check out those classes to see how its done. > Thanks Christopher, Hiren --------------------------------------------------------------------------- - Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: [EMAIL PROTECTED] -------- ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: [EMAIL PROTECTED]
