Abstract

For verifying timing properties of real-time distributed programs we investigate the worst-case response time of concurrent tasks which run independently but share logical or physical devices. For such tasks, a crucial factor for predicting the worst-case response time is to estimate the time spent waiting for synchronization events. We study the class of Client-Server distributed programs in which independent, time-critical tasks (Clients) are synchronized only through additional Server tasks, as recently suggested in real-time design guidelines proposed to enhance schedulability and synchronization analysis. Focussing on the timing analysis we reduce the general analysis problem to studying reduced program paths in terms of flow graphs in which the arcs are labelled with minimum and maximum execution time estimates. The first formal result shows that the problem of evaluating the worst-case waiting (blocking) time is NP-compIete. For a reduced problem version in which only operations involving communication are considered a conjecture was held that even for only 2 tasks the evaluation of the worst-case blocking time was NP-complete. We disprove this by constructing, and proving correct, a polynomial algorithm for its closed form solution which works even for an arbitrary number of tasks. The effectiveness and complexity of this algorithm are discussed, also regarding the quality of of the solutions as upper bounds for the original timing analysis problem.

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call

Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.