Re: [MiNT] Prusage(), Signals

[Frank Naumann <fnaumann@mail.CS.Uni-Magdeburg.De>]

Hello!

> Prusage():
>
> r[0] = process time in kernel
> r[1] = process time in own program code
>
> Does this mean I have to add those two times to get the overall time
> the process has been running? I guess so.

Yes.

> And what does "process time in kernel" mean? Do VDI and AES also count
> in here? E.g. if a VDI routine took a long time I will see that in
> r[0]?

Yes.

> This looks very similar to Pmsg() in mode 2 (send message and then
> wait for one). Andideally this will work, too. But since we have
> multitasking, the following might occur:
>
> A: Pexec(B)
>    (now the OS switches tasks to process B, so A has not executed Psigpause() yet)
> B: Pkill(A, SIGCONT)
> B: Psigpause()
> A: Psigpause()
>
> So this is my question:
> Will I have a deadlock now?

Yes.

> Or does A immediately wake up again,
> because the earlier SIGCONT signal was buffered? I read the docs, but
> they are ambiguous here!! It is not celar to me what happens with the
> signals.

If a signal is delivered to the process the following happen:

- the signal is first marked as pending for the process
- if the signal is not blocked by the process, the process is woken up and
  moved to the ready queue (if not already there)
- on the next context switch to the process the kernel check for pending
  signals; if there is something pending the signal handler for the
  process is invoked imediatly (instead restoring the context)
- now the signal handler run

- if a signal is blocked it's only marked as pending; nothing more is
  done
- if a signal is unblocked it's checked if the signal is pending; if
  yes the signal handler is invoked immediatly

This means, yes, you can get deadlocks with your simple model. To avoid
deadlocks you must block/unblock the Signals on the right places.

> I want to know this because I want to use the above scenario as a
> (bad) replacement for Pmsg() under MagiC. But of course I do not want
> deadlocks...

You should test if the signal semantic on MagiC is really compatible.


Ciao
   ...Frank

--
ATARI FALCON 040 // MILAN 060
-----------------------------------------
http://www.cs.uni-magdeburg.de/~fnaumann/
e-Mail: fnaumann@freemint.de