ocean-lang.org Git - ocean-D/blob - Ocean-concurrent

   1
   2 Concurency is important to make full use of modern
   3 hardware.
   4 Lots of tasks really don't benefit: they are boring
   5 data manipulation and UI management.  But when you
   6 have a CPU-intensive task, you really want to parallelize it.
   7
   8 And you want data-structures that allow this.
   9
  10 But if you don't have all that many CPUs, you want very
  11 light-weight tasks to do the work.
  12
  13 We definitely want data structures like bag and lists that
  14 can be accessed concurrently safely, and we want dependencies
  15 to be sufficiently clear that some normally-sequential steps
  16 can run in parallel.
  17 This is where message passing comes in - having a 'channel'
  18 that is used to pass a message from one code block to another
  19 can then be a simple variable, or can be a synchronization object.
  20 You might need a lot of such objects, so they need to be created
  21 dynamically - like stack-frames.
  22
  23 I probably need to experiment with some specific examples:
  24  - quick sort
  25  - unordered search
  26  - image scale
  27  - ..
  28
  29 The other perspective on concurrency is the need to be non-blocking,
  30 even when using a single CPU.  This needs to be more explicit,
  31 probably with a fork/join model.   This could look like
  32 a 'continuation' where we store code in a variable, but
  33 the code starts running immediately and the variable changes
  34 value somehow when the code completes.
  35
  36
  37 Having thought about this during my run this morning, my current position is:
  38 (mar 2019??)
  39
  40 1/ we have locking primitives, fields which indicate what lock protects them,
  41  and pointers which are typed to say what lock they own.
  42  Locks are generally nreader-xor-1writer and spin or wait on a queue,
  43   possibly dedicated, possibly chosen by hash.
  44  a refcount is a lock that is mostly in the nreader state.
  45  A 'writer' which frees the object might get queued at object creation.
  46
  47
  48 2/ we have "completions" in the language which are a bunch of code
  49   combined with some data state - a bit like an object, but described
  50   dynamically in-line.
  51   A completion can be created easily and might be:
  52   - run immedately
  53   - stored and run later
  54   - run asynchronously.  In this case the returned value is a queue
  55     that is easily waited on.
  56
  57
  58   A completion might return a 'channel' which returns a seqeunce of values.
  59   In the run-immediately case, this is like a loop.
  60   In the stored-and-run-later, it is like a generator.
  61
  62
  63 A completion combines code and data.  The data is sucked from the
  64 environment.  Any borrowed pointers need to have their owner too, and
  65 ownership needs to be duplicated or moved or whatever.
  66 For a generator, we need explicit "use" calls. So want them for regular completions
  67 too.??? or is "return" cleaner because it doesn't go to a channel exactly...??
  68
  69 I need a clean syntax for this.
  70
  71 foo := continuation
  72 ? no, I think that looks weird. I want it to be obvious from the start.
  73 But where do we store the handle?
  74
  75  cont foo:= code
  76
  77  fork foo:= code
  78