Concurrency in Unicon
This project concerns the design and implementation of concurrency features for the Unicon language. The Unicon language is the successor of the Icon programming language. As such, it inherits the co-routines capabilities of Icon. However, it does no contain a language construct for producing a true thread which may be simultaneously executed by a separate processor. In order to introduce such a capability into the Unicon language we will create a new op code for the i-code engine that will create a new thread of execution in the i-code interpreter itself. We also need to modify the Unicon compiler to recognize the new language syntax and generate the new i-code op code.
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
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 not 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
Issues / Questions
There is no doubt there is 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 underlying GUI implementation routines may not be thread safe and these vary between platforms (X versus Win32).
Since the icon translator is implemented with yacc it should hopefully not be too terribly nasty to splice in some new syntax relating to concurrency.
The scanner for icon is hand written (i.e. not lex generated). Thus, it will need to be modified to tokenize any new language tokens.
What to do about initially code sections in threaded environment
Here is a sketch of one approach.
Unicon will utilize monitors and threads as its concurrency mechanism. These can be implemented by having the Unicon compiler translated them into semaphore operations in the concurrency extended icon.
Icon would be extended to contain semaphores.
syntax might look something like
s := &sem
This would create a binary semaphore and assign it to s. This semaphore would be implemented by having the interpreter call the Pthread create mutex routine.
s:=&csem(int)
This would create a counting semaphore initialized to the value int in similar fashion using the corresponding Pthread routine..
Intrinsic functions wait and signal would be added.
wait(s)
signal(s)
The internal representation of the semaphore in the interpreter would constitute a new type. The type function would need to be augmented to return the appropriate strings. The value of the semaphore would simply be an integer used to distinguish one semaphore from another. The integer would be used as a subscript into a table that holds the actual Pthreads semaphore values.
Implementing icon threads by creating them from expressions
The creation of threads within the interpreter raises some interesting alternatives and questions. One fundamental issue is whether thread should be created out of procedures or expressions. The coroutne concept has been pushed down to the expression level in icon giving rise to a programming style utilizing coexpressions. One might think then that this is the level at which concurrency should be introduced. Although this could be done, attempting to implement actual threading at the expression level gives rise to many problems relating to context. ... add discussion ...
Implementing icon threads by creating them from procedures.
This approach is much more straightforward to implement than the previous approach. Since all procedures in icon occur at the top level, i.e. there is no nesting of procedure declarations, any procedure in an icon program could be used to create a thread.
Creating processes in Icon.
In addition to adding the ability to create threads a capability could be added to create processes. Since the semantics of a process does not imply a shared address space (unless further arrangements are made) this could be implemented by having the interpreter fork. Interprocess communication and synchronization would be achieved through the standard POSIX interface. A pipe could be opened between a parent and its child providing a standard interprocess stream for communication. A different class of semaphores would be used to map to OS level interprocess semaphore capabilities distinguishing them from Pthreads mutexes.
Remote processes
References: See The MT Icon interpreter for a version of the Icon interpreter that supported threads.