Table of Contents
This chapter describes the threading model used by the Core and the issues a programmer must deal with when the use of application-level threads is planned.
First of all it must be noted that the Core is not a multithreaded library. Although there may be multiple Core threads running in parallel the API exposed to the application is not thread-safe. This may look like a serious design flaw but hey, the Massiv is a distributed MMO game middleware intended to be ran on multiple nodes, not on a single CPU. If the Core had been multithreaded, so would have been the distributed application. This would result in application complexity growth (locking on the application level would be essential), performance losses due to the need for synchronization (distributed locking is often innefective) and the risk of distributed deadlocks. Needless to say that the transparences the Core currently supports would probably have to be relaxed or could not be implemented reliably at all.
The Core itself allocates worker threads for its own needs. These are used by the file system to implement asynchronous IO, for example. Besides these threads there may be one or more simulation threads that are scheduled cooperatively. Only one thread runs in a moment. However the Core is free to switch among the simulation threads whenever it is entered to perform a blocking operation. From the point of view of the application, it runs cooperatively and thread switches occur at well-known places only ("preemption points").