Concurrent API update. (#1949)

CONCURRENCY.md

@@ -20,11 +20,11 @@
  each mutable object is owned by the single worker, but ownership could be transferred.
  See section [Object transfer and freezing](#transfer).
 
-  Once worker is started with `startWorker` function call, it can be uniquely addressed with an integer
+  Once worker is started with `Worker.start` function call, it can be uniquely addressed with an integer
  worker id. Other workers, or non-worker concurrency primitives, such as OS threads, could send a message
- to the worker with `schedule` call.
+ to the worker with `execute` call.
  ```kotlin
-   val future = schedule(TransferMode.CHECKED, { SomeDataForWorker() }) {
+   val future = execute(TransferMode.SAFE, { SomeDataForWorker() }) {
        // data returned by the second function argument comes to the
        // worker routine as 'input' parameter.
        input ->
@@ -36,19 +36,18 @@
       // Here we see result returned from routine above. Note that future object or
       // id could be transferred to another worker, so we don't have to consume future
       // in same execution context it was obtained.
-      result ->
-      println("result is $result")
+      result -> println("result is $result")
    }
 ```
- The call to `schedule` uses function passed as its second parameter to produce an object subgraph
+ The call to `execute` uses function passed as its second parameter to produce an object subgraph
  (i.e. set of mutually referring objects) which is passed as the whole to that worker, and no longer
  available to the thread that initiated the request. This property is checked if the first parameter
- is `TransferMode.CHECKED` by graph traversal and just assumed to be true, if it is `TransferMode.UNCHECKED`.
- Last parameter to schedule is a special Kotlin lambda, which is not allowed to capture any state,
+ is `TransferMode.SAFE` by graph traversal and just assumed to be true, if it is `TransferMode.UNCHECKED`.
+ Last parameter to `execute` is a special Kotlin lambda, which is not allowed to capture any state,
  and is actually invoked in target worker's context. Once processed, result is transferred to whoever consumes
  the future, and is attached to object graph of that worker/thread.
 
-  If an object is transferred in `UNCHECKED` mode and is still accessible from multiple concurrent executors,
+  If an object is transferred in `UNSAFE` mode and is still accessible from multiple concurrent executors,
  program will likely crash unexpectedly, so consider that last resort in optimizing, not a general purpose
  mechanism.