Dans les exercices suivants, on va distribuer des calculs. Afin de ne
pas trop ``polluer'' le réseau et les machines de toutes les salles,
vous ne démarrerez des programmes et des serveurs que sur votre machine,
la machine immédiatement à gauche de la votre (ou à droite selon),
et immédiatement derrière vous (ou devant, selon).
Chacun lancera rmiregistry en indiquant un numéro de port, selon sa place
dans la salle TD, comme indiqué dans la figure suivante.
Implémenter le calcul de π en parallèle avec la toujours la même formule : \[ \pi = \int_0^1 \frac{4}{1+x^2} dx \approx \sum_{i=1}^n \frac{1}{n} \frac{4}{1+((i-\frac{1}{2})\frac{1}{n})^2}. \] A nouveau, nous allons implémenter le paradigme maître/esclave, en le distribuant réellement sur plusieurs machines. Un maître va lancer N esclaves chargés de calculer les sommes partielles \[ P_k = \sum_{i=(k*n)/N+1}^{((k+1)*n)/N} \frac{1}{n} \frac{4}{1+((i-\frac{1}{2})\frac{1}{n})^2} \, , \; k=0,\ldots,N-1, \] puis faire la somme des résultats partiels.
On pourra se contenter dans un premier temps d'imiter ce qui est fait dans Hello et faire des appels bloquants.
On pourra soit implémenter un client/serveur non bloquant (par callback), soit (si vous avez moins de temps...) utiliser les threads JAVA pour rendre moins bloquants les appels aux esclaves (les serveurs).
Reprendre l'exercice du TD précédent, mais implémenter le schéma aux différences finies en Java/RMI et non plus sous CUDA.
On considère une base de données partagée accédée par des threads JAVA de deux types. L'un est le type lecteur, l'autre le type rédacteur. Les lecteurs sont des threads qui par définition ne peuvent que lire (interroger) la base de données. Les rédacteurs par contre peuvent lire et écrire. On suppose que la lecture parallèle de la même location dans la base de données est autorisée, par contre l'écriture en parallèle avec soit une lecture soit une autre écriture sur la même location doit être effectuée en section critique (exclusion mutuelle). On simulera (il ne sera pas nécessaire d'avoir une vraie donnée, une simple simulation des actions à l'écran suffit) le début de l'accès en lecture par la méthode (à écrire) startRead(), la fin par end Read(), le début de l'accès en écriture par startWrite() et la fin par endWrite().
On veut implémenter un tel système avec au moins la propriété suivante: aucun lecteur ne doit rester en attente sauf si un rédacteur a obtenu la permission d'utiliser la base de données. Peut-il y avoir des cas de famine?
On pourra également (optionnel) se poser la contrainte supplémentaire suivante: dès qu'un rédacteur est prêt, il doit effectuer son écriture aussi vite que possible.