dmitry.z...@gmail.com
unread,Feb 18, 2009, 8:15:20 PM2/18/09Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Phantom OS
We need to define semantics for sync primitives on user level.
Current low level code uses two types of sync stuff:
mutex take/release pair. is usual. only one thread can have mutex
taken.
sleep/wakeup pair. You call sleep on a "variable" (passing a closed
mutex), it opens (frees) a mutex and puts itself in a sleep
(indefinitely or for some time). If somebody calss wakeup for this
"variable", someone sleeping will be awaken. It then tries to
reacquire the mutex and returns with mutex acquired. Note that
releasing mutex and starting to sleep is atomic, which is really
necessary.
We need to be compatible with Java monitors here. It seems to be more
or less easy.
Note that for some kernel/snapshot design reasons Phantom app code CAN
NOT wait in syscalls (internal classes methods), as it will stop
kernel from snapping. So any wait/sleep must be implemented separately
- for example, syscall will return some special code and vitrual
machine will go wait on some default thread object for kernel to
finish syscall activity and let a thread to continue. This sleep must
be restartable as well - for example, it must be recorded in a
thread's state that this thread is sleeping. On the sleep finish
thread must check for 'in snap' kernel state.