GitStrapped provides a linearizable sub-semaphore for each STRAP (service-template-running-a-process).
Each sub-semaphore is responsible for eliminating race conditions as applications compete for device, network, and processor resources.
Sub-semaphores appear to the application user as a kernel, but sub-semaphores are not necessarily sub-kernels.
Sub-semaphores may run under a microkernel in userspace or they may be dedicated to a physical device, functioning as a monolithic kernel.
Sub-semaphores are not to be confused with a subset of mutual excluders (mutexes). Although a binary semaphore limits access to a single resource, making it shareable… semaphores may be constructed in such a way to allow for parallel execution across multiple processors.
Are you trying to say that a mutex is a type of semaphore? Yeah kinda… I’m saying that a mutex is an implementation of a binary semaphore, which at a given moment either provides application user(s) access to the (assumed to be limited) resource or it does not provide access to the resource. The mutex can run under a semaphore as a sub-semaphore in order to exclude when exclusion makes more sense, from a resource perspective.
In a parallel execution domain a principal semaphore may control sub-semaphores across nodes in a distributed system such as a parent semaphore controlling cluster of sub-semaphoric kernels or pseudokernels.
Cooperative multi-threading per node reduces overhead between threads if an application is sensible about its resource consumption. Cooperative multi-threading can exist in a subkernel where a superkernel manages subkernels with a pre-emptive scheme that slices up timeslots according to distributed resource availability.
You might be thinking “oh but the network bandwidth is such a bottleneck” which is why a supersemaphore instructs subsemaphoric pseudokernels to either pre-emptively slice time or give processes permission to access the hardware resources until a child exits or Elvis has left the building.