Support de cours en PDF sur le langage D pour la programmation distribuée, document de formation sur 19 pages par Cristina Videira Lopes et Gregor Kiczales .
Nous présentons dans ce cours le langage orienté objet pour la programmation distribuée appelé D. Le langage D utilise l’approche de programmation orientée objet pour permettre d’écrire le code de la fonctionnalité de base d’une application distribuée sans devoir traiter explicitement de la distribution et de la synchronisation. Séparer le code traite avec ceux problèmes.
Le cadre de langage D comprend: (i) Jcore, un langage orienté objet utilisé pour exprimer la fonctionnalité de base et l’activité du système; (ii) Cool, un langage utilisé pour exprimer la coordination des discussions; et (iii) Ridl, un langage utilisé pour exprimer des stratégies d’accès à distance. Un outil spécial appelé Aspect Weaver prend les programmes écrits dans les différentes langues et les combine ensemble pour produire un programme exécutable avec le comportement distribué spécifié. D s’appuie sur les langages orientés objet existants et adhère agressivement à la séparation syntaxique des problèmes de distribution. Les textes de programme D sont moins emmêlés et donc plus simples et plus réutilisables que leurs équivalents écrits en Java.
Supposons que nous souhaitons implémenter une classe de recherche de livre qui gère une association entre les livres et leurs emplacements physiques. La fonctionnalité de tels objets consiste en trois services: (i) un service de registre qui prend un livre et un emplacement, et enregistre la paire dans certaines variables internes; (ii) un service non enregistré qui prend un livre et l’élimine du registre; et (iii) un service de localisation qui prend une chaîne de clé, recherche dans les champs de chaîne des livres les correspondances possibles avec la clé, et retourne l’emplacement du premier livre qui lui correspond.
En plus de cette fonctionnalité de base, les localisateurs de livres devraient être en mesure de traiter plusieurs demandes simultanément. À cet égard, les localisateurs de livres présentent un comportement assez courant dans les systèmes concurrents: les accès «en lecture» (dans ce cas, le service de localisation) peuvent être effectués simultanément tout en bloquant temporairement tous les accès «en écriture»; Les accès ‘write’ (dans ce cas, register et unregister) ne doivent pas être effectués simultanément et doivent bloquer tous les autres services.
La dernière partie de la spécification est que les localisateurs de livres sont des objets de réseau, c’est-à-dire qu’ils peuvent être consultés à distance. Supposons, par exemple, qu’ils font partie d’une application de gestion de documents beaucoup plus volumineuse et que la base de données complète du livre soit gérée par un ou plusieurs autres serveurs. Afin d’accélérer les recherches, les localisateurs de livres devraient mettre en cache des informations sur les livres, à savoir leurs titres, auteurs et isbn.
La figure 1 montre une implémentation possible de cette spécification à l’aide de la fonction RMI (Remote Method Invocation) de Java et Java [15]. Pour des raisons de lisibilité, nous avons coloré le code en fonction de son rôle dans le programme: le noir s’applique aux fonctionnalités de base de la classe, le rouge au code de coordination et le vert au code pour l’accès distant.
Profitez de ce manuel de formation en PDF pour comprendre mieux le Langage D et enrichir votre connaissance.
Commencez à télécharger ce cours adapté pour vous et à apprendre Langage D.
58 4.1. THE COMPONENT LANGUAGE: JCORE One of the advantages of D is that its design is mostly independent of the details of the core OO language. WhileJcore is now a subset of Java, D could easily be adapted to work with C++ or Smalltalk. We assume that the reader ismoderately familiar with Java, and therefore we won’t say much about Jcore. We simply enumerate what was removedfrom Java to get Jcore, and why:· For purposes of semantic strengthening: the keyword synchronized ; and the methods wait, notify and noti-fyAll. This is to enforce that Jcore classes don’t do explicit synchronization.· For control of effort: interfaces and overloading of methods.(See class definitions in Figure 2) 4.2. THE COORDINATION ASPECT LANGUAGE: COOL Cool is a very simple language that provides constructs for dealing with mutual exclusion of threads, synchronizationstate, guarded suspension and notification. Coordination programs consist of a set of coordinators (see coordinator inFigure 2, in red) which are associated with Jcore classes on a name basis. A coordinator can coordinate more than oneclass at the same time. Coordinators can inspect the Jcore objects’ state, but they cannot modify it.4.2.1. MUTUAL EXCLUSION OF THREADSThe most basic synchronization need of object-oriented programs is defining which methods can be executed concurrentlyby different threads and which methods cannot. Part of this issue was discussed in section §3.1. Based on this observation,Cool provides two constructs for addressing this need, the selfexclusive and mutexclusive method sets. In eachcoordinator there is at most one selfexclusive set, but there can be many mutexclusive sets. Each method in-cluded in the selfexclusive set is executed by at most one thread at a time. Methods in the same mutexclusive set mutually exclude each other, meaning that they are never executed concurrently. 5 These two simple, but powerful,constructs reduce all the red code in Figure 1 (about 35 lines) to two lines of code in the aspect program in Figure 2. Whatthose two lines mean is that locate can be executed concurrently by several threads – because it is not in the selfex-clusive set – and that the execution of any of the three methods by one thread blocks the execution of the others byother threads – because they are in one mutexclusive set.4.2.2. SYNCHRONIZATION STATE AND GUARDED SUSPENSIONBesides controlling the exclusion rights, coordinators also manage the object’s synchronization state. Synchronizationstate is captured by condition variables ( cond ) which can be declared in the coordinator. Synchronization state changescan occur only on entry and on exit of the methods of Jcore objects, and this is captured by the on_entry and on_exit clauses. Guarded suspension is captured by the requires clause. The requires and on_entry con-structs are executed atomically. Notifications are issued automatically on changes of the values of condition variables.6 Programming the synchronization state consists of defining a number of condition variables and then defining re-quirements and state modifications for each of the methods of the Jcore classes. The example below shows the imple-mentation of the synchronization scheme of a concurrent bounded stack. Threads are suspended when wanting to pushelements in stacks that are full or wanting to pop elements from stacks that are empty. 5 Methods in mutexclusive sets are not self-exclusive, unless they also belong to the selfexclusive set.6 The language implementation can easily optimize the number of notifications, and only issue them if the new value is actually being usedas a waiting condition in some requires clause.