Service-Oriented Architecture Attributes Progress Report 4 – Thread Interaction

Service-Oriented Architecture Attributes Progress Report 4 – Thread Interaction

When I started making changes to support Component Specified Verification I made some modifications as well by adding some additional test components to produce different message combinations.  This broke the framework. 

It started out, if I remember correctly, with the timing of the message topics, their delivery, and their release.  Way back when during the predecessor of this personal project, there was the design goal of having the framework run in the same thread (APEX process) as the component that was interfacing to it to save process switching time.  I heard after I left – the only thing that I’ve heard about the project – that this approach was abandoned as not working.  When I started my personal PC based project I retained the same thread approach thinking I would find out why it became necessary to discard it.

The problem, of course, is that causing a new component to start running via a notification event (or periodically if not an Upon Demand component) can cause a component with a higher priority to run suspending the currently running thread that may be currently executing framework code.  For instance, when a component publishes a notification topic to cause another component to be run, that upon demand component will start immediately if it has a higher priority suspending the original component.  Therefore, the rest of its execution will be suspended as well as that of the framework to which it would return.  That delays the framework’s execution of the data buffer release of the delivered topic that has been read by the consumer component and hence no longer needed by it.

The newly running component can publish its own instance of a request that is also being requested by the suspended component.  When the second component finishes, the N-to-One Request/Response consumer component can then begin to run as having a priority intermediate to the first two.  This component will then produce a response to the first component before it has completed its execution that produced the request.

This caused a good deal of reevaluation as to when Read Queues were needed to contain multiple instances of a topic to be treated by a component and when multiple data buffers were needed when ordinarily only a single buffer is needed since it would be released before a new request or response would need the buffer. 

This likely answered why the original approach was abandoned for the aerospace project.  However, having solved some of these problems earlier as my own PC project proceeded, I continued the approach to see what would develop.  For the PC project, the problems are, most likely, greater since the number of threads available using Windows is quite limited so threads often run via time slicing.  Thus, threads of the same priority alternate with one running and then being suspended and another running and the various same priority threads alternating their execution.

After some unproductive approaches I have now succeeded once again and each request is delivered to its consumer and each data buffer is released after the consumer has had a chance to read the topic.