https://wiki.kram.nz/index.php?action=history&feed=atom&title=SE701%3AFB%3AUsability_and_Interoperability 2026-06-19T23:27:19Z Revision history for this page on the wiki MediaWiki 1.45.3 https://wiki.kram.nz/index.php?title=SE701:FB:Usability_and_Interoperability&diff=20&oldid=prev 2008-02-15T19:38:30Z

<p>New page: =NPMTR for “Non-Preemptive Multi-Threaded Resource�?.= Depend on the underlying operating environment, the service of a resource may behave differently. For example Archimedes uses a ...</p> <p><b>New page</b></p><div>=NPMTR for “Non-Preemptive Multi-Threaded Resource�?.=<br /> <br /> Depend on the underlying operating environment, the service of a resource may behave differently. For example Archimedes uses a run-time environment based on RTSJ, that allows the use of an event queue for each active FB. <br /> <br /> The execution environment stores any output event that&#039;s produced by any FB to the event stores of the corresponding subscriber FBs. Any active consumer FB issues a blocking read from its input event queue, allows the processes not to be suspended.<br /> <br /> However, the overheads may be large (monitoring latch, event queues, etc.), and the behavior of the system may be errorneous, queuing input events cause a combinatorial explosion of possible system states, making it difficult to predict if and when unsafe system behaviors may occur.<br /> <br /> ==Assumed resource model==<br /> # all threads that lead to event generation and propagation between FBs in the resource, and all processes that modify the values of FB output variables operate at the same priority<br /> # None of the threads may pre-emptively interrupt another<br /> # Threads in different resources may operate at different priorities as long as (i) and (ii) are satisfied<br /> # No FB instance in the resource may have an independent thread of execution except SIFBs.<br /> # SIFB may have multiple internal threads, as long as those threads that modify output variable values and/or cause output event generation meet conditions (i) and (ii)<br /> # All processing described in the critical region is performed in the same thread that caused the entry of the critical region<br /> # All processing associated with the occurrence of an event at an event input of a basic or composite FB shall be executed in the same thread that caused the issuance of the event at the other end of the associated event connection.<br /> <br /> It is a consequence of these last two rules that a whole<br /> “daisy chain�? of event connections executes as a critical<br /> region. For this reason it is important to ensure that algorithms<br /> be short pieces of code that do not block the execution<br /> of other threads in the resource that may be awaiting<br /> their turn. For algorithms, as in life, it is a good rule not to<br /> be greedy (short algorithm execution time). Where answers<br /> specific to this resource model are given, they will be identified<br /> with the notation NPMTR for “Non-Preemptive<br /> Multi-Threaded Resource�?.<br /> <br /> ==Essential difference of semantic execution approaches==<br /> Difference in the way how blocks in the network are activated which depends on the way of passing event signals between function blocks.</div>

Mark