Is it possible that semaphores, mutexes etc, could be implemented outside
the kernel as services of a resource manager, where message passing and
signals be part of the semaphore infrastructure. I believe QNX’s use of
Priority Inheritence upon a message-receivce could help in this aspect.
Not if you want to use the same API sem_* etc. But if you want to use your own API I guess it’s possible but I don’t see the point. Maybe you could explain what exactly you need to do?
Maschoen is right. Synchronization across the network would be the
advantage. But say, if I want to write my own QNX-like OS but do not want
to include semaphores etc in the kernel (primarily because semaphores are
boring to me, heh heh), what would be the disadvantages of having a
Semaphore Resource Manager.
This may sound silly, but in a architecture where resource sharing - except
shared-memory - is inherently synchronised / serialised with also the
provison of priority-inheritance, does one really requires kernel-semaphores.
Fine, with SMP one does require spinlocks but otherwise what else can qualify
semaphores?.
Sorry to keep this topic burning Mario… but IMHO even if there’s a slight
performance penalty by keeping semaphore-management outside the kernel,
one gains advantage like netwide shared-memory synchronisation etc. So, a
more sophisticated semaphore manager I suppose. Of course, I do not
presently know of all the issues involved with thread synchronisation in the
embedded environment.
Networked shared-memory is an oxymoron. Memory cannot be shared via network. I guess I shouldn’t say cannot, I guess it could be it would be a nightware to implement and have lots of caveats I think.
You mentioned thread synchronisation but semaphore are typical not about synchronisation they are about protecting shared data (like CriticalSection under windows).