[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
student for gsoc2008
- Date: Fri, 28 Mar 2008 09:46:42 +1100
- From: chrisj at rtems.org (Chris Johns)
- Subject: student for gsoc2008
Joel Sherrill wrote:
> I think entry/exit makes sense on potentially blocking
> synchronization primitives.
> Consider this sequence:
> + sem obtain blocks
> - context switch
> time passes - context switch back
> + sem obtain returns
> At the first context switch, without logging entry we do not know why
> it blocked. At the return point, without logging the exit we do not know
> the reason why it unblocked.
> It is just something that needs to be worked through. Do we log entry
> and exit to read()? If you don't you won't know if that blocked you
> or how many bytes were read.
> Hard issues..
Yes this nice example where the tool is being used in real-time to debug means
we need 2 calls. If the bug is the call never returns you never know it
happened which is not a useful tool.