You may use the Thread class to spawn new threads. Even in single-threaded programs, its static methods, such as sleep or yield, can be called to affect the execution of the current thread. New threads can be created either by subclassing Thread, or by instantiating a Thread instance directly. In both cases, a function that returns void and takes no arguments can be passed to the Thread constructor in the form of a delegate or function pointer.

import core.thread;
import std.stdio;
class MyThread : Thread {
  this() {
    super(&run);
  }
  private void run() {
    writeln("MyThread is running.");
  }
}
void myThreadFunc() {
  writeln("myThreadFunc is running.");
}
void main() {
  auto myThread1 = new MyThread;
  auto myThread2 = new Thread(&myThreadFunc);
  myThread1.start();
  myThread2.start();
}

There are C libraries and frameworks that provide a platform-agnostic way to create threads. Sometimes, such as when the C library requires the use of a custom thread handle for certain functions, it is necessary to use the foreign API to create new threads. This usually requires a pointer to a function that the new thread will call when it is executed. Any such threads should usually be registered with DRuntime inside the thread function by calling thread_attachThis.

extern(C) void threadFunc(void* data) {
  import core.thread : thread_attachThis, thread_detachThis;
  thread_attachThis();
  scope(exit) thread_detachThis();
}

Registering foreign threads with DRuntime is necessary to ensure that all required thread-local initialization is done. It's also important if the thread touches GC-managed memory. Before the GC scans any particular block of memory, it pauses the execution of all active threads. If a thread has not been registered with DRuntime, then the GC can't pause it. For this reason, you should always prefer to use the Thread class to create new threads in D, even when using C libraries. Threads should be created through third-party APIs only in the rare cases when it is unavoidable. Foreign threads should always be registered with DRuntime if they touch anything on the D side.

A Fiber, an alternative implementation of a coroutine, can be spawned in the same manner as a Thread, by subclassing or by instantiation with a function pointer.

The delegate or function pointer associated with a fiber is executed when the call member function is called. Execution happens in the calling thread, which is blocked until the yield function is called, as shown in the following example:

import core.thread;
import std.stdio;
void myFiberFunc() {
  writeln("Execution begun.");
  Fiber.yield();
  writeln("Execution resumed.");
}
void main() {
  auto fiber = new Fiber(&myFiberFunc);
  fiber.call();
  writeln("Execution paused.");
  fiber.call();
}

Always keep in mind the difference between a fiber and a thread. A Thread instance represents a system resource. Each system thread has its own copies of thread-local data, so any mutations of such data through the run member function of a Thread instance happen on local copies and will not be visible in other threads. Non thread-local mutable data should be protected through synchronization primitives. A Fiber instance does not represent a system resource, meaning it does not have its own copies of thread-local data. If there is any possibility that multiple threads can run the call function on a Fiber instance, then care must be taken to synchronize access to all data that can be accessed through that function. As long as the same thread executes the function every time, synchronization is only an issue with data that is not thread-local. We'll see a bit about synchronization in D shortly.

Applying __gshared to a module-scope variable in D is essentially the same as declaring any variable in C. It is entirely up to the programmer to ensure that access to the variable by multiple threads is properly guarded. The same holds true for member variables of aggregate types, with the added side effect that such variables are also static. For example, the declarations of shared1 and shared2 in the following snippet are equivalent:

class SharedMembers {
  __gshared static int shared1;
  __gshared int shared2;
}

__gshared is a necessity when declaring variables in C library bindings, but it should otherwise be a rarity in normal D code.

There are a few things to be aware of when applying the shared attribute to a variable. First, it must be understood that shared modifies the type.

int tlsVar;             // type == int
shared int sharedVar;   // type == shared(int)

This has consequences in how shared variables are used as function arguments and assigned to other variables. While value types can convert just fine, this does not hold with reference types or pointers, for example, a shared(int)* does not implicitly convert to int*.

Second, shared is transitive. Applying shared to an instance of an aggregate type means all of its members are also shared.

struct ShareMe {
  int* intPtr;
}
shared ShareMe sm;
int x;
sm.intPtr = &x; // Error!

Here, sm.inPtr = &x fails because &x yields int*, not shared(int*), which is the type of sm.intptr thanks to the declaration of sm as shared.

Third, the compiler prohibits any unprotected, non-atomic modification of a shared variable. In the following snippet, the second line is illegal:

shared int sharedInt;
++sharedInt;

In this case, the error can be avoided using a template function from the core.atomic module in DRuntime.

import core.atomic : atomicOp;
atomicOp!"+="(sharedInt, 1);

The synchronized statement creates a scope in which all variable accesses are protected by a mutex. When the scope is entered, the mutex is acquired (locked). When the scope is exited, the mutex is released.

private int _someInt;
void setSomeInt(int newVal) {
  synchronized {
    _someInt = newVal;
  }
}

The compiler will allocate a new mutex object specifically for each synchronized blocks. This behavior can be overridden by providing any expression that yields a class or interface instance for the synchronized statement to use. Every class instance has its own mutex which the compiler will use instead of allocating a new one. That said, it's considered good practice to use an instance of std.mutex.Mutex.

import std.mutex;
auto mutex = new Mutex;
synchronized(mutex) {
    ...
}

synchronized can be applied to class (but never struct) declarations. Doing so makes every member function of that class synchronized and causes the mutex associated with each instance of the class to be used as the monitor, meaning that it's equivalent to adding a synchronized(this) statement inside every function in the class. With this, only shared instances of the class can be instantiated and all member function calls will be serialized.

As I write, there are two issues to watch out for regarding synchronized classes. One is public member variables. Right now, it's possible to declare them in a synchronized class, but this can be problematic if they are mutable as it allows for non-synchronized mutation. It is expected that this will be deprecated at some point.

The second is the documentation at http://dlang.org/class.html#synchronized-classes says the following:

In practice, the compiler actually does allow synchronized to be applied to individual member functions. Again, instances of the class must be declared as shared. It is unlikely that this will change, as it is certain to break code in active projects. One such project is DWT, a port to D of the SWT library for Java (see https://github.com/d-widget-toolkit/dwt).

The DRuntime package core.sync contains several modules that expose primitives that can be used to manually implement synchronization for different behaviors. The package includes two types of mutexes, a generic recursive mutex in the mutex module, and a mutex that allows for shared read access and exclusive write access in the rwmutex module. Additionally, the modules condition, semaphore, and barrier provide eponymous primitives. If you're looking to implement lock-based data sharing yourself, this is a good place to start.

An atomic operation is one that appears to happen instantaneously. Such operations are safe in multithreaded programming because there is an inherent guarantee that only one thread can perform the operation at a time, meaning that no locks are required. The core.atomic module in DRuntime provides a handful of functions that allow for lock-free concurrency. Earlier, we observed how to use the template function atomicOp to convert the non-atomic operation of adding 1 to a shared(int) into an atomic one. Other functions in the module allow for atomic loads and stores, atomic compare and swap (cas), and atomic memory barriers (memory fences).

When using atomic operations, it's important to have a good grasp of memory ordering. Members of the enumeration core.atomic.MemoryOrder can be used with the atomicLoad and atomicStore functions to specify the type of memory barrier instruction the CPU should use in carrying out the operation. Although it's a talk related to C++, a good place to start is Herb Sutter's two-part talk from C++ and Beyond 2012, titled, atomic<> Weapons: The C++ Memory Model and Modern Hardware at https://isocpp.org/blog/2013/02/atomic-weapons-the-c-memory-model-and-modern-hardware-herb-sutter.