[Squeak-fr] Squeak et la concurrence

[Bernard Pottier]

Damien Cassou a écrit :

> alr a écrit :
>
>> (reps:)
>> Autre précision qui peut avoir son importance (?): je parle de 
>> l'implémentation de la VM windows, pas de la VM Unix.
>
>
> Comment fonctionnent la VM Unix ? Est-elle multi-threadé au niveau du 
> système ?
> _______________________________________________
> Squeak-fr mailing list
> Squeak-fr at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
>
>
> .
>
Squeak  *a un système* qui peut tourner sur du hardware
nu.

Noyau de synchronisation : ProcessorScheduler,
Timers : Delay
Synchro: Semaphore, SharedQueue, ..

Je reprends un peu les explications en essayant de les rendre plus lisibles
(avec une teinture Un*x plus que Windows).

Primitives:
La MV (machine virtuelle) d'origine est portable et comporte la
notion de méthode primitive (micro-code, matériel, extensions dans
un langage externe). Ces primitives apportent des fonctionalités
et permettent l'extension des services de la MV.

Elles peuvent s'exécuter en concurrence avec la MV dans les circonstances
suivantes:
* un processus smalltalk démarre la primitive et lui donne un sémaphore S
* la primitive s'exécute de manière asynchrone avec la MV (hypothese)
* le processus se bloque sur le sémaphore (wait)
* a la fin de l'opération la primitive actionne 'a la main' le semaphore 
(signal)
   en libérant le processus de haut niveau.

Je n'ai pas de sources sous la main, mais j'ai déja écrit du code de ce 
type,
et il n'y a pas de bloquage. Dans ce sens, oui, Squeak et Smalltalk en
général est un langage concurrent avec un noyau. Il faut simplement payer
le prix de l'interfacage du noyau lorsque l'on travaille sur un OS étranger.

Threads: processus poids léger, par opposition avec les processus systèmes
'lourds'. Ils partagent l'espace d'adressage du processus lourd. Donc
effectivement les processus Smalltalk sont des threads qui ne sont pas 
implémentés
avec les librairies du système sous-jacent.

Deux intérets:
1) permettre l'expression de la concurrence dans l'application
2) permettre l'utilisation du parallélisme

On a le point 1) avec le Noyau Squeak. On n'a pas le 2).
La page 
http://as.univ-brest.fr:30005/autresrfrencestechniquesmulti-threadingipc/multi-threading/
montre les temps d'exécution d'un produit de matrice sur un monoprocesseur,
un processeur hyper-threadé et un bi processeur. Il manque le multicore 
Athlon
que nous avons sous la main (je vais l'ajouter).

On voit que sur cette 'appli' découpée en threads, un multi processeur
va dépasser les performances du monoprocesseur.

Ce que sait faire la librairie thread de Linux, le noyau Smalltalk ne sait
pas le faire. On n'ira pas plus vite avec plusieurs processus dans l'état
actuel des choses, alors que le langage permet des constructions 
implicitement
parallèle. Les méthodes sur les collections, par exemple, pourraient 
etre implémentées
en processus légérs exécutant des collect:, do: , etc.. (ou des 
évolutions) finissant
sur une barrière de synchronisation.

En plus, pour faire des serveurs performants, il faut pouvoir pondre de la
concurrence à revendre (voir les efforts de Sun sur Java). La question
du support multiprocesseur dans la MV Squeak est incontournable. La
probabilité qu'elle soit traitée sur un interface thread natif est élevée,
meme si cet interface est un bricolage en regard de ce qui a pu etre
fait plus proprement par ailleurs. Il y a aussi des débats processus-objets
sur une liste 'Occam' que je suis également (http://www.wotug.org)


Bien cordialement
Bernard Pottier
UBO.