Messages postés par "yoch"
3 messages sont invisibles car dans un sujet inaccessible.
Sujet | Date | Extrait |
---|---|---|
mardi 19 juillet 2016 à 22h52 | Il y a de petites erreurs subtiles dans ton nouveau code. - Le fait que tu incrémente `i` dans tous les cas, même si tu n'entre pas dans le if, est problématique. - En enlevant le booléen `won`,… | |
mardi 19 juillet 2016 à 15h52 | > Enfin du coup aurais-tu une idée de comment arrêter un à un les rouleaux, après chaque saisie-clavier, sans utiliser de structure de données et de `isAlive` ? Par exemple (avec une référence sur… | |
mardi 19 juillet 2016 à 07h52 | Avec 12 choix parmi 15 mots, ça fait quand même plus de 200 milliards de possibilités. Pour avoir une chance d'y arriver, il faut que tu vise quelque chose comme 1 million de tests / seconde au minim… | |
lundi 18 juillet 2016 à 23h58 | Ton code pour `HandlerInput` est plutôt laid... Tout d'abord, ce n'est pas forcément ce qu'il y a de plus propre de gérer ça dans un thread et de quitter tout avec un System.exit(). Mais ce qui me… | |
lundi 18 juillet 2016 à 19h58 | Ça risque d’être chaud bouillant... $\dfrac{30!}{(30-12)!} = 41430393164160000$ arrangements possibles. Admettons que tu teste 10000 combinaisons par seconde, il te faudra juste 131374 ans pour l… | |
lundi 18 juillet 2016 à 14h50 | Je n'ai pas dit ça. Tout dépend de ce que tu cherche a protéger. Par exemple, il faut bien voir que `System.out.print(writer.cmpt.getVal());` est équivalent aux deux lignes suivantes : ```java i… | |
dimanche 17 juillet 2016 à 20h47 | > Le souci c'est qu'il n'y a pas que `getVal` mais d'autres instructions qui n'appartiennent pas à la classe `Counter`. > > [...] > > Encore le `sout(writer.cmpt.getVal()))`, je comprends qu'on… | |
dimanche 17 juillet 2016 à 18h54 | Non, pourquoi donc ? Tu peux rendre toutes les méthodes `synchronized` (y compris `getVal`), et enlever le `synchronized` du `Lancher` qui n'a plus d’utilité du coup. Du reste, je n'aurais pas mis… | |
samedi 16 juillet 2016 à 21h08 | Plusieurs remarques : - D’après ton énoncé (qui est resté dans mon cache), les rouleaux ne sont pas censés s’arrêter en meme temps, si je comprend bien : > Lorsque l'utilisateur tape sur n'import… | |
vendredi 15 juillet 2016 à 16h43 | Non, ce n'est pas pareil. Un sémaphore peut être manipulé par deux threads différents, alors qu'un verrou doit être libéré par le thread qui l'a acquis. D'ailleurs, l'usage d'un sémaphore (même binai… | |
lundi 11 juillet 2016 à 22h07 | > (juste : "file d'attente" = file où sont rangés les threads qui attendent la libération du verrou OU BIEN celle où sont rangés les threads qui attendent un `notify` ou encore les deux ? =/) Je n… | |
lundi 11 juillet 2016 à 15h41 | [[attention]] | les termes que j'emploie ne sont pas forcement exacts du point de vue de Java, je laisse les précisions terminologiques a quelqu'un de plus pointu sur le sujet. > Dans la JavaDoc … | |
samedi 09 juillet 2016 à 20h55 | Avant tout, petit rappel sur le fonctionnement d'un verrou : lors d'une demande d'acquisition, si le verrou est déjà pris, il met le processus qui a fait la demande en attente, et le réveille lorsque… | |
vendredi 08 juillet 2016 à 16h44 | > Du coup je viens de changer le code. J'ai ajouté un attribut d'instance `sons : ArrayList<Find>`, que je remplis dans la méthode `search` chaque fois qu'un `Find` (donc un thread) est créé. Puis j'… | |
vendredi 08 juillet 2016 à 09h05 | Tu as parfaitement raison, mais dans mon exemple je n'utilise pas `getValue()` depuis un thread. On pourrait imaginer qu'il sera appelé depuis le thread principal une fois les autres threads terminés… | |
vendredi 08 juillet 2016 à 03h21 | Dans ce cas il n'y a plus aucun intérêt d'utiliser des threads, puisque ton code est devenu séquentiel a cause du `join` qui suit immédiatement le `start`. | |
jeudi 07 juillet 2016 à 22h03 | > @Yoch : c peut être partagé ou bien local (respectivement si on donne le même c à 2 objets X, et si on donne deux c différents à 2 objets :X) non ? Tout a fait. >> "Le plus souvent, le synchr… | |
jeudi 07 juillet 2016 à 19h56 | Je ne serais pas aussi catégorique, il n'est jamais inutile de savoir comment les choses fonctionnent sous le capot. Et il est très important de bien comprendre le *threading-model* de Java lorsque l… | |
jeudi 07 juillet 2016 à 13h46 | > Qu'est-ce que tu appelles "ressource locale à un thread" ? Je sais que les processus UNIX créés par `fork` possèdent exactement le même code et donc, à leur création, les mêmes variables ; ces dern… | |
jeudi 07 juillet 2016 à 08h21 | > Pour les cas complexes, n'hésite pas à faire un tour du côté du package java.util.concurrent.locks dans la doc. > Là-dedans il y a des éléments classiques de la programmation concurrente avec des … | |
jeudi 07 juillet 2016 à 01h16 | Avant tout, il faut comprendre le fonctionnement d'un verrou : c'est un objet qui une fois acquis par un thread, ne peut plus être acquis par un autre thread avant que le premier thread ne l'ait libé… |