Hello, I have been thinking about adding Concurrency features to Unicon. Below are some ramblings on the subject.
Since Unicon assumes POSIX as its base, the obvious method for creating concurrency in Unicon is to utilize the POSIX threads package (Pthreads) within the i-code interpreter. In order to cause the interpreter to create a thread within itself executing i-code instructions concurrently with other threads in the interpreter we will require a new i-code op-code. Similarly thread management calls from the Pthreads library for destroying threads and performing various types of synchronization between the threads will require addition i-code op-codes (or possibly an argument following a single new op-code indicating sub function). In order to be able to generate and utilize these new op-code(s) two things must be done (1) the i-code interpreter must be modified to recognize and implement the new op-code(s) (2) the icon translator must be modified to recognize new syntax for concurrency features and must be made to generate the new op-code(s) as appropriate. It is the icon compiler that must be modified in that we will be generating new instructions for the i-code machine. This cannot be done at the Unicon compiler level as it emits icon code not i-code instructions. Once the new concurrency features have been added to icon, new concurrency features can be added to the Unicon compiler which can be compiled into icon code utilizing the icon concurrency features. The concurrency features implemented at the Unicon level need no be the same as those actually implemented at the icon level. For example, concurrency at the Unicon level could look like monitors much the same way the Java implements concurrency. The Unicon compiler could then translate the monitor syntax into elementary semaphore operations. The semaphore operations could be implemented in icon and translated very directly into Pthreads operations. Tasks 1. Devise concurrency model and syntax for Unicon 2. Devise concurrency model and syntax for Icon 3. Modify Icon compiler to recognize new syntax and emit appropriate instructions 4. Modify i-code interpreter to recognize and implement new op-codes 5. Modify Unicon compiler to recognize new concurrency syntax and emit appropriate Icon. Issues / Questions Re: 4. There is no doubt code currently in the i-code interpreter that is not thread safe. This code will need to be identified and instrumented to utilize Pthread mutexes private to the interpreter itself. This will be further complicated by the fact that many of the GUI implementation routines may be not thread safe and they vary between platforms (X versus Win32). ???1 I notice that the icon translator has context switch code already in it. Since the only concurrency construct in icon is the co-expression I do not understand why it needs an actual context switch. Re: 3. Since the icon translator is implemented with lex and yacc it should not be too terribly nasty to splice in some new syntax relating to concurrency. ---- My web page where I am keeping my thoughts on this is http://faculty.cs.wwu.edu/meehan/Research/Programming%20Languages/concur rency_for_unicon.htm Sincerely, Michael Meehan [EMAIL PROTECTED] ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
