European Association of Software Science and Technology

Log in
Workshop on Graph Transformation and Concurrency

Workshop on Graph Transformation and Concurrency

An informal workshop, to be held in Leicester on 24 - 26 January 2013, to discuss foundations and applications of concurrency in graph transformation.

General Discussion

  • Public

General Discussion

Started by Reiko Heckel 1988 days ago Replies (2)

For contributions that do not fit into any of the themes given, or if you are not sure where it fits best.

Replies

  • Dirk Janssens 1986 days ago

    My main remark is that we should perhaps be somewhat more ambitious, and more general, in choosing the topics and question. I would not like to be bogged down in technical details and miss a chance to discuss our goals, and the contributions we ultimately intend to make. At the same time we  should admit that the impact of theory on current practice, e.g. programming multicores, is not as decisive as one would have liked, an that there may be a need to question the basic assumptions and models. 

     

    I am convinced that it is at least worth investigating wether GT can contribute to concurrency theory in a fundamental way, but that requires looking at questions such as the following.

     

    - What is the problem with "concurrency" ?  What is it  that we are trying to solve? If we want to make the point that GT is useful for this area, we should look more carefully than we did so far at what are the crucial questions. Implicitly you identify two obvious ones: programming concurrent systems, and analyzing them. But in order for that observation to be useful, we should be more precise about what we mean by "a concurrent system"; I think the descriptions used so far are too idealized, perhaps to the point that they become unrealistic. That seems to be the view of a number of authors (e.g. Peter Sewell et al. and the work on relaxed memory models). Issues that are often conspicuously absent are the cost of communication, the characteristics of the processors, etc.  

     

     

    - A lot -I would even say, most-  of concurrency theory has been based on process algebras; and clearly one of the main assets this approach has to offer is a syntactical structure: programs are terms, not just sets of rules. This syntactic structure, as we all know, leads to the proof techniques that allowed one to build the theory.  But if we want to have a suitable syntactic structure for GT systems, we will have to come up with the right notions for composing such systems. And come up with something simple and elegant enough to convince practitioners to use it. 

    On a related point: since GT systems , or at least the ones I like, are based on node replacement, it always has seemed more natural to me to compose them by gluing processes over common nodes. This is different from the idea of synchronization over common actions used in most of concurrency theory. In my opinion this could provide an interesting counterpart for the existing theory of concurrency. But again, the proof of the pudding is in the eating: what exactly is the problem to be solved?

     

    Looking forward to the workshop

    Dirk

  • Tom Ridge 1971 days ago

    Dirk - just to say that I think this post raises quite a few interesting issues.

    If anyone is interested in talking about multicore, weak memory etc, I worked with Sewell for quite a few years on weak memory stuff.

    I think process calculi were interesting for modelling certain types of distributed and mobile computations. And it gave us some interesting theory and proof techniques. However, it didn't address many of the hard aspects of such systems, and arguably the domain of *mobile* computations is rather small (the world today is not the world of mobile agents).

    Anyway, I would like to hear what people think about your last question: "what exactly is the problem to be solved?"

    Cheers

     

Replies

In order to participate in this discussion, you must be a member of Workshop on Graph Transformation and Concurrency.