1  Resources

Latest Source code (Concurrent Cyclone with inference for extended region annotations)	(Type System)
Latest Source code (Concurrent Cyclone with extended region annotations)	(Type System)
Outdated Source code (Concurrent Cyclone with extended region annotations)	(Type System)

2  Introduction

• Concurrent Cyclone has been based on Cyclone 0.8.2.
• Cyclone 0.8.2 has been modified so that it can properly bootstrap with GCC 4.x
• 64-bit machines are still unsupported.

3  Design Decisions

3.1  New Features

• Function declaration:

      t foo[<`r1::K,...,`rn::K>]
      (t1 x1, ..., t_n x_n
              [; effect] [:region_order])
             [@ieffect( {....} , ... , {...} )]
             [@oeffect( {...} , ... , {...} )]
             [@throws(...) @throwsany @nothrow]   
             [@re_entrant]  
       

  • Naming convention: the new kind of regions desribed here is called xregions whereas traditional Cyclone regions will be called nregions.
  • A future goal is to integrate the two kinds of regions into a single one but this is not the case in this implementation.
  • @ieffect and @oeffect are the function input and output effects for xregions. The default effect when they are not present is the empty effect. Both effects consist of a list of atomic effects of the form {‵region_name,‵region_count,‵lock_count,‵parent_region_name}. ‵region_name corresponds to a typical region name also found in a traditional Cyclone effect. The region and lock counts are ad-hoc. They can be of the form ‵natN₁,‵natN₂ (pure capability) or ‵barN₁,‵natN₂ (impure capability), where N₁ and N₂ are natural numbers. The ‵parent_region_name is also a typical region name and is optional. The (calling) functions that omit parent region names must ensure that parents are live after the call. The ‵region_name must be an xregion and the parent name is present it can be an xregion or the heap region (‵H).

  • The effects (input and output) have been kept separate from the traditional Cyclone effect. This is not the way to go but for the moment we don’t support inference so integrating the two would require to write lots of explicit annotations.

  • xregions are not placed on the stack frame. Therefore, exceptions must be known in order to determine that a region is properly deallocated. There exist three kinds of annotations for exceptions: @throws(…) that enumerates (…) all exceptions that may be thrown from the function body. The @nothrow is just an abbreviation for @throws(). Finally, @throwsany allows us to describe any exception that may be thrown. The latter feature may be useful for library prototypes and existing code.

  • A function is @re_entrant (probably not the best name) when it disallows access to global variables and regions (‵H, ‵U or ‵RC). A @re_entrant function can only invoke @re_entrant functions.

• spawn(e₁,e₂): The semantics of this operation is straightforward. Spawn a new thread and apply e₁ on e₂. e₁ must be @re_entrant, @nothrow and have an empty @oeffect annotation. The traditional Cyclone effect of e₁ must be empty. The types of values passed to spawn must not contain global regions (Unique, Heap or Reference counted) cannot be passed to spawn.

• region child @ parent: The "parent" handle is used for allocating a new sub-region with handle "child". The parent region must be live. The child region is initially accessible - no locking is required. The parent handle can be the heap region handle.

• New kinds: XRgnKind or ‵r::X. xregions, which can be safely shared and deallocated early, fall under this kind. ::X was initially a sub-kind of RgnKind, but it is unsafe to allow this. This is not an elegant design decision. Ideally, all regions should fall under ::R.

• Library functions (core.h):

       extern void xdec(region_t<`r>;{})
       @ieffect({`r,`bar1,`nat0})
       @nothrow;
  
       extern void xinc(region_t<`r>;{})
       @ieffect({`r,`bar1,`nat0})
       @oeffect({`r,`bar2,`nat0})
       @nothrow;
  
       extern void xldec(region_t<`r>;{})
       @ieffect({`r,`bar1,`nat1})
       @oeffect({`r,`bar1,`nat0})
       @nothrow;
  
       extern void xlinc(region_t<`r>;{})
       @ieffect({`r,`bar1,`nat0})
       @oeffect({`r,`bar1,`nat1})
       @nothrow;
      

It should be noted that the type system also allows non-binary region and lock capabilities to be passed to the above functions.

4  Future Goals

• XPtrKind <: XRgnKind: Unique pointers (allocated within regions — reaps) could be reprented as follows:
  • Introduce a pointer allocation construct pointer<‵r> ptr @ parent_region = new e. ptr will be a pointer to a region ‵r of kind XPtrKind. Assume XPtrKind is represented as ::P.
  • Introduce a pointer deallocation construct free_ptr( ‵a @‵r::P ptr ) @ieffect( ‵r,‵bar1,‵nat0).
  • The advantage of this encoding is that no swap operations are required and it is easier to use unique pointers (less annotations maybe).

• fixrgn<‵r> s: Assuming that ‵r is of ::X kind and has a positive lock and region capability, we can move ‵r for the scope of statement s from ::X to ::R. Therefore, it can be used as a traditional (thread-local) Cyclone region. ‵r is transformed from a xregion effect to a traditional region effect for the scope of s. The original effect is restored at the end of s.

5  Examples

Short examples can be found at 0.8.3/tests/ioeffect/pass.

This document was translated from L^AT_EX by H^EV^EA.