Ada

[ADA] Multitâche, exclusivité d'accès à une variable

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : [ADA] Multitâche, exclusivité d'accès à une variable

Pschitt

Voila un bout de code qui est censé garantir l'exclusivité d'accès en écriture à une variable mais j'ai du mal à expliquer comment :

Code :

task VAR_PROTEGEE is
entryLIRE(X:out ITEM);
entryECRIRE(X:in ITEM);
end;
task body VAR_PROTEGEE is
V:INTEM;
begin
accept ECRIRE(X:in ITEM) do
V:=X;
end;
loop
select
accept LIRE(X:out ITEM) do
X:=V;
end
or
accept ECRIRE(X:in ITEM) do
V:=X;
end
end select;
end loop;
end VAR_PROTEGEE;

L'explication est elle que tant qu'on est en lecture(LIRE) de la variable V, la tâche ECRIRE étant située également dans le bloc (loop ... end loop) la variable V est protégée en écriture ?

Publicité

nraynaud

lol

Pschitt a écrit :

Voila un bout de code qui est censé garantir l'exclusivité d'accès en écriture à une variable mais j'ai du mal à expliquer comment :

Code :

task VAR_PROTEGEE is
entryLIRE(X:out ITEM);
entryECRIRE(X:in ITEM);
end;
task body VAR_PROTEGEE is
V:INTEM;
begin
accept ECRIRE(X:in ITEM) do
V:=X;
end;
loop
select
accept LIRE(X:out ITEM) do
X:=V;
end
or
accept ECRIRE(X:in ITEM) do
V:=X;
end
end select;
end loop;
end VAR_PROTEGEE;

L'explication est elle que tant qu'on est en lecture(LIRE) de la variable V, la tâche ECRIRE étant située également dans le bloc (loop ... end loop) la variable V est protégée en écriture ?

c'est le select ...end select qui exclut que 2 entrées soient activent en même temps, ce qui veut dire dans ton cas que les lectures sont exclusives entre elles, les écritures sont exclusives entre elles et les lectures sont exclusives par rapport aux écritures et les écritures sont exclusives par rapport aux lectures.

En gros un seul point d'exécution au plus a le droit de se trouver dans un select.

Il existe une solution plus fine à base d'objets protégés, qui t'auraient permis d'avoir des lecture concurrentes et des écritures exclusives.

dsls

Exactement. Si mes connaissances Ada ne sont pas trop rouillées, ça devrait donner (attention, Ada 95 only):

Code :

protected type Var_Protegee is
function Read return Item;
procedure Write (a_Value : in Item);
private
V : Item;
end Var_Protegee;
protected body Var_Protegee is
function Read return Item is
begin
return V;
end Read;
procedure Write (a_Value : in Item) is
begin
V := a_Value;
end Write;
end Var_Protegee;

Message édité par dsls le 04-02-2003 à 16:52:06

nraynaud

lol

Dsls a écrit :

Exactement. Si mes connaissances Ada ne sont pas trop rouillées, ça devrait donner (attention, Ada 95 only):

Code :

protected type Var_Protegee is
function Read return Item;
procedure Write (a_Value : in Item);
private
V : Item;
end Var_Protegee;
protected body Var_Protegee is
function Read return Item is
begin
return V;
end Read;
procedure Write (a_Value : in Item) is
begin
V := a_Value;
end Write;
end Var_Protegee;

pas testé mais rien à redire. C'est même mieux car tu as une fonction qui retourne un résultat pour la lecture et pas un vieux passage de la valeur de retours par effets de bord => plus clair, plus simple.

BifaceMcLeOD

The HighGlandeur

Vous auriez un lien qui explique les types protégés d'Ada sur le Web ? A part le bon vieux LRM, je n'ai rien trouvé sur AdaHome...

BifaceMcLeOD

The HighGlandeur

En fait, je ne situais pas comment, dans le code du type protégé de Pschitt, le compilateur Ada pouvait autoriser les appels concurrents à la fonction et pas à la procédure. Dans le code, tien ne les distingue explicitement (à part le fait que l'une est une fonction et l'autre une procédure).

J'ai trouvé ceci cependant pour répondre à ma question :

Citation :

Within a protected body we can have a number of subprograms and the implementation is such that (like a monitor) calls of the subprograms are mutually exclusive and thus cannot interfere with each other. A procedure in the protected body can access the private data in an arbitrary manner whereas a function is only allowed read access to the private data. The implementation is consequently permitted to perform the useful optimization of allowing multiple calls of functions at the same time.

Extrait de cette page : http://www.adaic.com/standards/95r [...] 1-2.html#9

nraynaud

lol

BifaceMcLeOD a écrit :

Citation :

Extrait de cette page : http://www.adaic.com/standards/95r [...] 1-2.html#9

C'est la différence classique fonction/procédure :
une fonction est un machin à qui on applique des arguments (0 ou plus arguments) et dont on attend un résultat. Dans certains langages, la machin en question n'a même pas de droit de faire un effet de bord (affectation de variable par exemple), c'est pas fait pour.
Un procédure est une instruction qui une fois exécutée a modifié l'état de l'environement (en changeant la valeur d'une variable, en poussant dans un stream).

Evidement, la plupart des langages mélangent allègrement tout et les déceloppeurs n'ayant jamais eu cette notion clairement enseignée mélangent (par ex. en faisant des procédures avec un paramètre out au lieu d'une fonction sans effet de bords).

D'où la logique du comportement des objets protégés :
les fonction mattent mais ne touchent pas : elles peuvent matter à plusieurs.
les procédures touchent : problème de concurrence -> exclusivité.

Les entries sont en fait des procédures qui peuvent être gardées : la garde est une expression booléenne qui, si elle est fausse au moment de l'appel de l'entry bloquera l'appellant jusqu'à ce qu'elle devienne vraie, sans bloquer les appels de fonction sur l'objet. Si tu avais fait un "wait" en début de procédure, tu aurais perdu la possibilité d'envoyer des appels de fonction sur l'objet pendant l'attente -> ça tient pas la charge.

BifaceMcLeOD

The HighGlandeur

Mais du coup tu ne peux pas faire de fonction du genre :

function Func returns TheValueType is
begin
if not-initialised then
initialise(); -- Appel d'une procédure qui initialise l'objet.
end if;

return theValue;
end Func;

puisque du coup, il y a effet de bord.

Si c'est le cas, je suppose que tu vas me répondre, l'utilisateur n'a qu'à appeler explicitement la procédure d'initialisation, quitte à ensuite lever une exception dans la fonction si tout n'est pas convenablement initialisé...

dsls

Citation :

Si c'est le cas, je suppose que tu vas me répondre, l'utilisateur n'a qu'à appeler explicitement la procédure d'initialisation, quitte à ensuite lever une exception dans la fonction si tout n'est pas convenablement initialisé...

C'est ça. Dans ton cas bien précis, tu peux faire une procédure avec ta valeur en out, ce qui remplace la fonction et laisse plus transparaître les effets de bord de l'appel. Ou mieux, tu encapsules ton type protégé dans une variable contrôlée, comme ça plus besoin d'appel explicite à Initialize(). Bon par contre coupler type protégé+type contrôlé amène parfois à certaines siouxeries pas évidentes (principalement à cause des types contrôlés d'ailleurs) ... Mais bon, n'est pas fortement typé qui veut

Message édité par dsls le 05-02-2003 à 23:43:01

BifaceMcLeOD

The HighGlandeur

Du genre ? :??:

Publicité

nraynaud

lol

BifaceMcLeOD a écrit :

Mais du coup tu ne peux pas faire de fonction du genre :

function Func returns TheValueType is
begin
if not-initialised then
initialise(); -- Appel d'une procédure qui initialise l'objet.
end if;

return theValue;
end Func;

Je ne pense pas que l'utilisateur a à se préocuper de ce genre de détails. Soit la valeur d'initialisation doit être fournie par l'utilisateur et tu te fondes sur une sorte de "construction" avec le discriminant par ex. (piqué du lien plus haut) :

protected type Counting_Semaphore(Start_Count: Integer := 1) is
entry Secure;
procedure Release;
function Count return Integer;
private
Current_Count: Integer := Start_Count;
end Counting_Semaphore;

Ou alors la valeur par défaut est intrinsèque et donc tu peux la coder en dur :

protected type Counting_Semaphore is
entry Secure;
procedure Release;
function Count return Integer;
private
Current_Count: Integer := 0;
end Counting_Semaphore;

Je fait part d'une réflection qui m'est venue à l'esprit en cherchant de tête à répondre à ta question (car en réalité on est pas exactement dans le même modèle, ton initialisation est "lazy", fainéante donc à la demande, si elle est coûteuse et a une probabilité importante d'être inutile, c'est un choix. Mon initialisation est "eager", motivée et donc systématiquement exécutée à l'instanciation du type).

Donc je me disait, il suffit d'appeler la procédure d'initialisation de l'objet dans le if : appeller une procédure de type protégé est exclusif, comme on est dans le if, l'exclusivité n'a lieu qu'une fois et tout va bien. Sauf qu'il y a un problème de synchronisation :
2 threads rentrent dans la fonction , rentrent dans le if (c'est les 2 premières) et chacun attend que l'autre se barre de la fonction pour exécuter l'initialisation -> ça peut durer longtemps.
Il doit y avoir moyen de faire plus intelligent, peut-être à base d'entries gardées, mais j'ai pas d'idées.

Message édité par nraynaud le 07-02-2003 à 03:30:44

FORUM HardWare.fr

Programmation

Ada

[ADA] Multitâche, exclusivité d'accès à une variable

Sujets relatifs
[JS \| PHP] Variable de JS à PHP	je chercher a proteger l'acces a une page web avec .htaccess
Cherches script pour surveiller un déni d'accés à un rep htaccess	faire prendre une valeur a une variable dans une requete SQL
Recherche présence d'une variable	Problème d'accès avec Tomcat 4.1
[C] affichage du contenu d'un variable en graphique ...	[JAVASCRIPT] variable globale à plusieurs pages
Incrémenter le nom d'une variable	Acces a distance a PhpMyAdmin via EasyPHP
Plus de sujets relatifs à : [ADA] Multitâche, exclusivité d'accès à une variable

Page générée en 0.079 secondes