Regulator Delete

[Joel Sherrill]

Hi

Starting another thread so we can focus on this without all the code in the
way.

Chris' concern was that deleting the regulator includes deleting the
delivery thread and that could cause the delivery function to leave
resources like mutexes in an unknown state. He asked about a coordinated
shutdown/delete.

In thinking about this, I realized that you cannot delete a partition while
buffers it has given to a user are outstanding. It
returns RTEMS_RESOURCE_IN_USE. This means the rtems_partition_delete() call
will fail in Chris' scenario because 1+ buffers would still be outstanding.

My thought is to not allow the user to delete a regulator instance unless
all buffers are released (e.g. in the pool). The buffers are logically in
one of four states: in the unused pool, held by Source, pending delivery,
or in the process of being delivered.

The application will have to perform some coordination to ensure all
buffers are back in the pool. The source needs to quit producing and all
messages pending delivery need to either be delivered or flushed. I'm
proposing the following:

+ cannot delete unless all buffers are in the unused pool (e.g. none
"obtained")
  - none need to be released
+ add method to flush messages pending delivery
+ add info method with number of buffers outstanding (e.g obtained but not
released)
   - later maybe add more statistics.

The application would have to coordinate the clearing of the regulator by:

(1) stopping the Source from obtaining buffers and sending to the regulator
(2) flush the pending undelivered message OR wait for them to be delivered
(3) wait for there to be no outstanding messages

Then it could be deleted.

I considered adding a way to have the regulator stop accepting input and
stop delivering but that does not address the issue of getting the buffers
back which the Source may have. When the current message being delivered
finishes, the buffer will be released. Ultimately, the application has to
stop producing input and clear the "work queue" somehow. I think I have
defined a fairly straightforward way to do that.

How does this sound?

--joel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230719/9c603acc/attachment.htm>