[Squeak-fr] Re: Squeak et la concurrence

[alain rastoul]

wow
je suis impressionné et je ne regrette pas de t'avoir titillé un peu :-)
remarque, je savais à qui j'avais affaire ;-)

Je comprend très bien - enfin il me semble - ta réponse sur les process 
smalltalk, les primitives et sémaphores et qu'il soit possible de le faire, 
mais je regrette qu'aujourd'hui les mécanismes et l'implementation 
existants - du moins de ce que je connais sous windows - ne permettent pas 
de résoudre directement ce problème - quoique pour odbc g pense pas que ca 
soit un problème bloquant.

C'est  vrai que le fait que la vm du langage soit écrite avec lui-même  (le 
langage) est la preuve d'un grand potentiel - d'autres ont essayé  avec 
d'autres moyens pour java sans résultat concret au niveau grand public - cf 
la vm java jalapeno d'ibm.

D'ailleurs ce qui me frustre en général avec squeak c'est ca : il y a un 
potentiel énorme, une approche du développement vraiment différente , mais 
il y a de tels  manques que c'est presque impossible de le faire accepter 
comme plate forme de développement dans une entreprise qui veut s'appuyer 
sur des "standards" de développement et ne veut pas financer de 
développement supplémentaire.
Peut-etre que le fait qu'il se répande au niveau de l'enseignement 
informatique pour les grands ou pour les enfants, changera les choses à ce 
niveau.


Salutations
Alain

"Bernard Pottier" <pottier at univ-brest.fr> a écrit 
dans le message de news: 4372F8A2.2030701 at univ-brest.fr...
> 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.