v0.4.0

https://github.com/sociomantic-tsunami/dmxnet/milestone/5?closed=1

Migration Instructions

NDarray must have null handles when calling Executor.outputs

mxnet.Executor

When obtaining the outputs of an Executor all NDarray instances passed to
the method outputs must have a null handle. For migration you can call
freeHandle on NDArray instances with non-null handles
(array.handle !is null). This will release all data associated with the
NDArray instance. This freeing used to happen implicitly under the hood when
executing the outputs method. The migration requires this release of
resources to be explicit in calling code. This reflects a design principle that
the user should control the lifetime of resources while dmxnet states what it
assumes about those.

If the handles of the passed NDArray instances are null no changes need to
be made.

Synchronized read-only data slice for NDArray.data()

mxnet.NDArray

The data method of NDArray is changed to return a read-only slice (i.e., a
slice of const elements). The added const implies that code writing
elements of the returned slice has to be changed. There is no direct
replacement. The closest option is to use the copyFrom method to copy all
elements of a slice into an NDArray.

Also the returned slice is synchronized. That means the method waits for all
pending writes to finish prior to returning. Code performing waitToRead()
(prior to calling data) manually should be removed.

Features

Provide function to trigger shutdown of MXNet engine

mxnet.API

The function notifyShutdown is added to notify MXNet to shut down its
execution engine. You may consider shutting down the engine manually to
avoid/reduce races on process exit.

Support multi-threaded MXNet engines

mxnet.MXNet

The changes to NDArray.data along with its required migrations enable the use
of multi-threaded MXNet engines. Unit and integration tests pass for all
engines and the restriction to the single-threaded NaiveEngine has been
removed. Note though, that on process exit there is still a race after
executing unittests. The race is likely to be caused by dmxnet interacting with
MXNet while MXNet is cleaning up at process exit. This issue is still open and
has only been partly addressed by instructing MXNet to shutdown. This makes the
race less likely to occur.