l'exécution du bloc de code atomiquement

Comment voulez-vous répondre à la question suivante?

Une méthode d'une classe java contient un bloc de code qui doit être
exécuté de manière atomique. Expliquer, à l'aide de pseudo-code, comment vous
permettrait de s'assurer que ce bloc de code est exécuté automatiquement

Aurais-je atteindre cet objectif en faisant la méthode ..

public final AtomicInteger x = new AtomicInteger(0);

d'assurer l'instruction get retourné:

x.get()

et si je le voulais pour incrémenter la valeur de x puis-je faire?

x.getAndIncrement();

Atomiquement à l'égard de quoi?
désolé, je ne suis pas sûr, c'est tout ce que nous avons pour la question. il est passé à l'examen de la question et nous n'avons pas été donné l'exemple de réponses
Cette question est beaucoup trop vague pour être répondu.
Lire sur les verrous, sémaphores, et de synchronisation pour vous obtenir a commencé. Aussi, apprendre ce blocage est.
C'est la question/titre censé être automatiquement ou automatiquement corriger?
À la lecture de la question, pourquoi pensez-vous qu'il serait automatiquement?
Parce que je n'ai jamais entendu parler de "atmoically" dans la programmation, et parfois les gens ne l'épeler correctement.
Jetez un oeil à ACIDE transactions, puis suivre le lien pour l'Atomicité.

InformationsquelleAutor germantom | 2013-06-03

41

La réponse dépend de votre définition de "atomique"

Je sais de trois valide définitions pour atomic:
1. Atomique comme dans synchronisé: un seul thread peut exécuter le code en même temps;
2. Atomique comme dans l'ACIDE: la totalité de l'action/bloc qui se passe, ou rien de tout cela n';
3. Atomique comme dans l'onduleur: une fois le bloc démarre, il ne peut pas être interrompu, même par les tâches de commutation.
Le premier est probablement ce que votre professeur voulait dire, et il est assez facile à réaliser (voir ci-dessous).

La deuxième atomiques (comme dans l'ACIDE) peut être approximée. Voir ci-dessous.

Le troisième tout simplement ne peut pas être garantie en Java il ne fournit pas l'accès à la "sections critiques" primitives nécessaires pour uninterruptibility. Heureusement, le besoin est assez bien limitées aux systèmes d'exploitation et les pilotes de périphérique.

Atomique comme dans synchronisé

C'est relativement simple: il suffit de joindre votre bloc de code dans un bloc synchronisé. J'ai montré comme un discret bloc ci-dessous, mais il y a d'autres options:
```
public void doSomethingQuasiAtomic() {
   synchronized (exampleLock) {
      //Your code block goes here. 
      //Only one thread will ever be in this block at a time.
      ...
   }
}
```
Atomique comme dans l'ACIDE

Il n'y a pas de cas solution pour ACID atomicité, mais il peut être approchée à l'aide d'synchronisé code. Pour ce faire, chacune des parties de l'action doivent être rangés de manière réversible.

C'est de cette façon que j'avais en approche:

Pour les besoins de la discussion, supposons qu'il y a un multipart action que vous devez faire sur un objet que nous appellerons exampleObj, que vous avez trois actions à effectuer, ce qui peut être en toute sécurité inversée, et que tous les accès à example est synchronisé sur exampleLock.
```
    synchronized(exampleLock) {
        boolean actionOneDone=false;
        boolean actionTwoDone=false;
        boolean actionThreeDone=false;
        try {
            actionOneDone=doActionOne(exampleObj);    //or perhaps exampleObj.doActionOne();
            if(actionOneDone) actionTwoDone=doActionTwo(exampleObj);
            if(actionTwoDone) actionThreeDone=doActionThree(exampleObj);
        } catch (Exception ex) {
            //Whatever seems appropriate here.
        } finally { 
            if (! (actionOneDone && actionTwoDone && actionThreeDone)) {
                /* At least one part failed.  Back out the completed actions in reverse order.  
                 * Note that we never need to reverse action three since if it completed, so did the others.
                 */
                if (actionTwoDone) {
                   reverseActionTwo(exampleObj);    //or perhaps exampleObj.reverseActionTwo();
                }
                if (actionOneDone) {
                   reverseActionOne(exampleObj);
                }
            }
        }
    }
```
- Intéressant! Je viens de voir me donner cela comme un test de réponse 😛
- bien dit, monsieur! clair et concis.
- Sujet Atomique comme dans de l'ACIDE, je voudrais ajouter que si (actionOneDone) actionTwoDone=... et de même pour l'action de trois. Sans que vous devez faire l'inverse pour tous les trois actions. Aussi, si une action échoue, vous n'avez pas besoin d'essayer d'autres. Dans son ensemble, je l'aime très universel formulation. Je suis à la résolution de la tâche dans la vraie vie maintenant et j'ai pensé seulement beaucoup plus de solution spécifique. +1.
- bon plus. J'ai été prévoyant l'doAction* méthodes que de lancer des exceptions quand ils échouent, mais ce n'est pas obligatoire, et je ne le dis pas. Je vais modifier pour inclure votre suggestion.
InformationsquelleAutor CPerkins
2

Je crois que la réponse attendue était quelque chose comme ceci:
```
public class A {
    public void foo() {
        //.. some code
        doSomething(); //the critical part
        //.. come code
    }

    public synchronized void doSomething() { //this is a synchronized method
        //the critical code
    }
}
```
L'exécution de doSomething() n'est pas vraiment atomique (Avertissement: il est très différent de l'atomicité), mais le synchronisé mot-clé garantit que seul un thread peut entrer dans l'exécution de cette méthode (sur une instance de A). Je pense que c'est ce qu'ils voulaient dire à la place de l'atomicité.

Ici est une autre question à propos de l'atomicité en Java. Vous pouvez trouver quelque chose d'utile là-bas.
- C'est très différent de l'atomicité. D'autres fonctions peuvent toujours observer l'objet dans un état incohérent.
- C'est sans doute que la question faisait allusion, mais un synchronized méthode ne garantit en aucune manière l'atomicité.
- Oui, mais la question n'a évidemment pas de sens, donc je pense que c'est juste mal exprimé. Je pense qu'ils voulaient dire que l'atomicité dans le sens que l'imbrication des instructions dans la section "atomique" bloc est exclue. Je sais que c'est pas vrai atomicité, mais ils parlent de "bloc de code" donc ils ont probablement ne signifie même pas AtomicInteger ou quoi que ce soit.
- je pense que vous avez raison au sujet de la AtomicInteger. si j'ai la place de faire une référence à un objet qui servira de verrouillage: 'private static Object x = new Object();' puis utilisez la commande suivante dans le bloc pour qu'il la garde. cela fait-il sens? " synchronisé (x){}'
- Que ferait que bloquer à l'intérieur de cette méthode thread-safe, mais n'importe quel objet à l'intérieur de ce bloc peut encore, éventuellement, être modifiés en dehors de lui. Donc, cela dépend vraiment de l'atomicité à l'égard de quelque chose.
- Oui, comme @Sotirios dit.
InformationsquelleAutor Mifeet

Vous devez vous connecter pour publier un commentaire.