Concurrency
Spawning Concurrent Tasks
V's model of concurrency is going to be very similar to Go's.
For now, spawn foo()
runs foo()
concurrently in a different thread:
[!NOTE] Threads rely on the machine's CPU (number of cores/threads). Be aware that OS threads spawned with
spawn
have limitations in regard to concurrency, including resource overhead and scalability issues, and might affect performance in cases of high thread count.
There's also a go
keyword. Right now go foo()
will be automatically renamed via vfmt
to spawn foo()
, and there will be a way to launch a coroutine with go
(a lightweight
thread managed by the runtime).
Sometimes it is necessary to wait until a parallel thread has finished. This can
be done by assigning a handle to the started thread and calling the wait()
method
to this handle later:
This approach can also be used to get a return value from a function that is run in a parallel thread. There is no need to modify the function itself to be able to call it concurrently.
If there is a large number of tasks, it might be easier to manage them using an array of threads.
Additionally for threads that return the same type, calling wait()
on the thread array will return all computed values.
Channels
Channels are the preferred way to communicate between threads. V's channels work basically like
those in Go. You can push objects into a channel on one end and pop objects from the other end.
Channels can be buffered or unbuffered and it is possible to select
from multiple channels.
Syntax and Usage
Channels have the type chan objtype
. An optional buffer length can be specified as the cap
field
in the declaration:
Channels do not have to be declared as mut
. The buffer length is not part of the type but
a field of the individual channel object. Channels can be passed to threads like normal
variables:
Objects can be pushed to channels using the arrow operator. The same operator can be used to pop objects from the other end:
A channel can be closed to indicate that no further objects can be pushed. Any attempt
to do so will then result in a runtime panic (with the exception of select
and
try_push()
- see below). Attempts to pop will return immediately if the
associated channel has been closed and the buffer is empty. This situation can be
handled using an or {}
block (see Handling options/results).
Channel Select
The select
command allows monitoring several channels at the same time
without noticeable CPU load. It consists of a list of possible transfers and associated branches
of statements - similar to the match command:
The timeout branch is optional. If it is absent select
waits for an unlimited amount of time.
It is also possible to proceed immediately if no channel is ready in the moment select
is called
by adding an else { ... }
branch. else
and <timeout>
are mutually exclusive.
The select
command can be used as an expression of type bool
that becomes false
if all channels are closed:
Special Channel Features
For special purposes there are some builtin fields and methods:
The try_push/pop()
methods will return immediately with one of the results
.success
, .not_ready
or .closed
- dependent on whether the object has been transferred or
the reason why not.
Usage of these methods and fields in production is not recommended -
algorithms based on them are often subject to race conditions. Especially .len
and
.closed
should not be used to make decisions.
Use or
branches, error propagation or select
instead (see Syntax and Usage
and Channel Select above).
Shared Objects
Data can be exchanged between a thread and the calling thread via a shared variable.
Such variables should be created as shared
and passed to the thread as such, too.
The underlying struct
contains a hidden mutex that allows locking concurrent access
using rlock
for read-only and lock
for read/write access.
Shared variables must be structs, arrays or maps.