Need advice on bounds checking approaches

[Joe Buck]

Greg McGary <gkm@eng.ascend.com> writes:
> 
> > Is there some other advantage to memory-barrier semantics wrt. bounds
> > checks that I'm overlooking?
> 
> I just thought of one: in a flat-memory-model system (say an embedded
> system), it might useful to have a policy whereby a task is terminated
> immediately upon detection of a bounds violation, and it's desirable
> to terminate it before it has a chance to scribble on some other
> task's memory.  OTOH, this is tricky business: you need some means of
> releasing resources locked by the newly terminated task and rolling
> back any partially completed work.  It sounds like a ton of work to
> implement correctly, so the benefit of memory-barrier semantics is not
> easily realized.

If the function that terminates the task is supplied by the RTOS (or can
be overriden), then the RTOS can take care of releasing resources owned by
the task that were provided by the RTOS (e.g. semaphores, allocated memory
segments, reserved ports) when the task is killed.