Snap-stabilizing committee coordination

Abstract

In the committee coordination problem, a committee consists of a set of professors and committee meetings are synchronized, so that each professor participates in at most one committee meeting at a time. In this paper, we propose two snap-stabilizing distributed algorithms for the committee coordination. Snap-stabilization is a versatile property which requires a distributed algorithm to efficiently tolerate transient faults. Indeed, after a finite number of such faults, a snap-stabilizing algorithm immediately operates correctly, without any external intervention. We design snapstabilizing committee coordination algorithms enriched with some desirable properties related to concurrency, (weak) fairness, and a stronger synchronization mechanism called 2-Phase Discussion. In our setting, all processes are identical and each process has a unique identifier. The existing work in the literature has shown that (1) in general, fairness cannot be achieved in committee coordination, and (2) it becomes feasible if each professor waits for meetings infinitely often. Nevertheless, we show that even under this latter assumption, it is impossible to implement a fair solution that allows maximal concurrency. Hence, we propose two orthogonal snap-stabilizing algorithms, each satisfying 2-phase discussion, and either maximal concurrency or fairness. The algorithm that implements fairness requires that every professor waits for meetings infinitely often. Moreover, for this algorithm, we introduce and evaluate a new efficiency criterion called the degree of fair concurrency. This criterion shows that even if it does not satisfy maximal concurrency, our snap-stabilizing fair algorithm still allows a high level of concurrency.

A scheduler for SCADA-based multi-source fusion systems

“…The approach by Ruiz et al [45] might also be used in our context, but our experimental results also prove that it is not efficient enough because it requires to perform some global computations that are costly and it periodically requires to freeze the whole system to know the status of every rendez-vous. The recent proposals by André et al [1] , Bensalem et al [4] , Bonakdarpour et al [7] , Brook et al [10] , and Jongmans and Arbab [26] also require to instrument the agents to build a distributed scheduler into them, which is not generally possible in our context due to the limitations of the computing boards; furthermore, Bensalem et al's [4] and Bonakdarpour et al's [7] proposals deal with a weaker level of fairness that cannot deal with rendez-vouses that get enabled or disabled depending on the logic of the system.…”

“…The first research path was explored by Joung [30] , the second one was explored by Ruiz et al [45] , but, to the best of our knowledge, nobody has explored the third one since it does not seem realistic. Recently, André et al [1] , Bensalem et al [4] , Bonakdarpour et al [7] , Brook et al [10] , and Jongmans and Arbab [26] have focused on enforcing fairness by instrumenting the agents so that a distributed scheduler is built into them.…”

“…The previous problem is related to a liveness property called fairness [16,25,34,53]. In the literature, there are many proposals to enforce fairness, but most of them cannot be adapted to our context: some proposals were designed to deal with two-way rendez-vouses only [3,5,35,49,56,57,60], but typical rendez-vouses in our context coordinate many more agents; others require to instrument the agents to build a scheduler into them [1,4,7,10,26], which can only be simulated by means of wrappers that are not generally possible to implement in low-end computing boards; some of them [4,7] cannot deal with rendezvouses that get intermittently enabled or disabled along an execution, which hinders applying them to our context; and some of them require to use shared memory [42], which is an advanced hardware feature that is not available in low-end computing boards. There are two proposals that could be adapted [30,45], but our experimental analysis confirms that they are not efficient enough in our context because they drove our experimental system into as many as 1 102.77 and 1 458.65 criticalfailure states per hour, respectively.…”