Wyniki wyszukiwania - BazTech

Ograniczanie wyników

3 Fundamenta Informaticae

Znaleziono wyników: 3

Liczba wyników na stronie

Wyniki wyszukiwania

Sortuj według:

Ogranicz wyniki do:

CCS(25,12) is Turing-complete

Gorrieri R.

Fundamenta Informaticae

2017

Vol. 154, nr 1/4

145--166

CCS(h,k) is the CCS subcalculus which can use at most h constants and k actions. We show that CCS(25,12) is Turing-complete by simulating Neary and Woods’ universal Turing machine with 15 states and 2 symbols.

An Operational Petri Net Semantics for A2CCS

Gorrieri R., Versari C.

Fundamenta Informaticae

2011

Vol. 109, nr 2

135-160

A2CCS is a conservative extension of CCS, enriched with an operator of strong prefixing, enabling the modeling of atomic sequences and multi-party synchronization (realized as an atomic sequence of binary synchronizations); the classic dining philosophers problem is used to illustrate the approach. A step semantics for A2CCS is also presented directly as a labeled transition system. A safe Petri net semantics for this language is presented, following the approach of Degano, De Nicola, Montanari and Olderog. We prove that a process p and its associated net Net(p) are interleaving bisimilar (Theorem 5.1). Moreover, to support the claim that the intended concurrency is wellrepresented in the net, we also prove that a process p and its associated net Net(p) are step bisimilar (Theorem 5.2).

Supporting Secure Coordination in SecSpaces

Gorrieri R., Lucchi R., Zavattaro G.

Fundamenta Informaticae

2006

Vol. 73, nr 4

479-506

In this paper we investigate security problems which occur when exploiting a Linda-like data driven coordination model in an open environment. In this scenario, there is no guarantee that all the agents accessing the shared tuple space are trusted. Starting from a formalization of some typical security properties in the standard Linda coordination model, we present a novel data-driven coordination model which provides mechanisms to support the considered security properties. The first of these mechanisms supports logical partitions of the shared repository: in this way we can restrict the access to tuples stored inside a partition, simply by limiting the access to the partition itself. The second mechanism consists of adding to the tuples some extra information which permits to authenticate the producer of a tuple or to identify its reader/consumer. Finally, we support the possibility to define access control policies based on the kind of operations an agent performs on a tuple, thus discriminating between (destructive) input and (non-destructive) read permissions on each single tuple.