Bonjour à tous !
 
j'aimerai savoir s'il est possible de faire du temps réel en java avec des sémaphores par exemple.  
Quelqu'un connait des truc a ce sujet ou bien un site sympa ?
merci d'avance

c'est pas possible de faire du temps réel en java

vraiment sur que c'est pas possible ?

schmur > J2ME possède un profil temps réel, J2SE ET J2EE, c'est niet de chez niet.

ok merci
faut faire les truc soit meme alors

non, va voir la doc de J2ME, le profil temps réel doit y être décrit.

connais pas j2me mais je vais m'y plonger dedans
merci

-- > un programme dont "l'horloge de vie" est claquée sur l'horloge du mur.
 
Dans la réalité, il faut qu'on puisse borner le temps d'exécution de chaque étape du programme par un nombre en rapprot avec ce qu'on fait dans la vraie vie.
 
Par exemple, en robotique, il faut pouvoir piloter un bras de robos finement, on prendra autour de la miliseconde. En fondrie, le pilotage de four à arc se fait à 2-3 min (bien que le temps de réaction réel du four soit de l'ordre de 2 heures).
 
En général, il s'agit du temps de réaction entre le moment où le programme reçoit une info et le moment où il émet des ordres issus de cette info.

par contre j'ai pas bien compris le rapport dans le post initial entre temps réel et semaphore ... c'est bien de la prog temps réel qe tu veux shmur ? t'es sûr que tu confonds pas avec de la prog parallèle ?

benou > parce qu'on fait souvent de la synchronisation de tâches en temps réel, et que c'est trop la merde de respecter le planning et de partager les ressources (ordonnanceurs de 40 000 types différents, systèmes pour pas perdre sa priorité etc.).

c'est un peu chinois pour moi, j'ai jamais fait de prog tps réel ... mais merci pour l'explication

moi non plus, mais j'ai vaguement survolé les cours.

moi j'ai même pas eu de cours la dessus  

apparament dans java 1.5 il y a des classes semaphores.
je vais les etudier un peu

C'est quoi la définition du temps réel ?
 
Un système temps réel est un system qui analyse son environnement en continue et apporte des réponses suivant les résultats des observations.
 
Si on se borne à cette définition : JAVA permet de faire du temps réel puisqu'il possède des boucles(while, for, etc.....) et qu'il implémente un système de threads qui permet de faire plusieurs observations du système.
 
Le seule bémole serait la granularité du language, mais à ce moment là il a des questions spécifiques aux projets entrepris qu'il faut se poser :
Ai-je besoin de scruter mon système tous les 5 µ secondes, pour répondre aux besoins ?
Les gains de productivité dus à l'utilisation de JAVA(Phases de tests moins longues, durée des projets raccourcis....) ne compensent-ils pas cette faible granularité ?

non. du temps réel c'est que tu observes et contrôle un procédé à une vitesse adaptée et que ton système d'information est capabel de respecter les contraintes temporelles sans jamais faillir. Avec Java tu ne peux pas, pour la simple et bonne raison que tu ne peux pas borner le délai de réaction. Borner strictement. Imagine ce qui se passe si le GC se déclenche au moment où tu dois prendre la décision de couper l'alimentation d'un robot parce qu'une anomalie a été détectée ? si tu prends 5ms de retard, ça peut être l'accident.

tiens, un nouvel expert émerge.

 
5ms c'est géré par JAVA.
Java ne gère plus à partir de la picron seconde.
Je suis vraiment curieux de savoir combien de projet nécéssitent une précision supérieure à la picron seconde.

Qui ça moi ?    

c'est plutot EExtasEE qui a raison
RT n'a rien a voir avec une reponse dans un temps defini (d'ailleurs c'est une des grosses pieges du RT)
il s'agit de pouvoir assure la bonne reponse lors de l'evenement qui la demande et pas d'assurer que ca arrive dans grand max x m ou µ secondes

j'adore les multis qui surgissent le vendredi.

Merci,
d'ailleur en lisant les autres réponses au thread, j'ai vu que J2Me avait plus un profile RT que J2EE......  
Une fois que vous avez lu ma réponse précédente, vous savez désormais que le RT ne dépend pas de l'API(Jdk) utilisée.

Multis?  

bon le boulet, il va falloir dégager maintenant. y'a des gens qui pourraient se mettre à croire ce que tu dis.

Pardon ?

http://sic.epfl.ch/SA/publications [...] ge9ag.html
 
et concernant java
https://rtsj.dev.java.net/
et c'est pas le seul site traitant ca

allez Norbert manges un danny ça ira mieux

1) la définition, je l'ai filé il y a 2 jours, exemples à l'appui
2) je vois pas le rapport avec linux
3) ça ne fait pas de java J2SE un truc temps-réel, même pour un four à arc.
 
 

arf
ce que tu comprends pas c'est que RT c'est quasi indépendant du language ou de l'API, donc que ce soir J2SE, J2Me, J2EE ou MIDP c'est pareil, c'est INDEPENDANT

1) et alors? j'ai pas vu ta definition ni le topic en question
2) aucun rapport mis a part le fait qu'il y a des gens qui pensent pouvoir faire du RT sous linux meme si c'est pas un os RT. mais le but de mon lien c'etait de donner une source a la definition tres pertinente que j'ai cite  
3) si tu le dis... t'as forcement raison, les autres boulets qui essaie de specifier ca font forcementfausse route    

je parle de la VM.
 
Je vais être franc avec toi : tu n'as exactement *rien* à m'apprendre sur le temps réel.

1) elle est dans le topic, en réponse à la question de --
2) j'en ai rien à foutre
3) s'ils sortent une spec différente, c'est bien parce que l'actuelle ne l'est pas.

c'est peut etre vrai, mais c'est pas pour autant que tu donnes l'impression d'avoir compris le but et la philosophie temps reel
 

 
lol ah bon alors je dois surement faire erreur, si tu est modo tu peux effacer toutes les conneries que j'ai dites.
 
sorry for disturbing

Je me permet d'ajouter ma reponse a ce flame-thread juste pour preciser un petit point qui a mon avis est a la base de la grande incomprehension qui regne ici...
 
En fait, j'ai remarque que le terme Temps Reel n'avait pas la meme signification d'un point de vue industriel que d'un point de vue 'service'.
Je m'explique; la veritable (au sens academique) definition de RT est bien celle donnee par nraynaud, a savoir
"Dans la réalité, il faut qu'on puisse borner le temps d'exécution de chaque étape du programme par un nombre en rapprot avec ce qu'on fait dans la vraie vie"
Ce qui signifie en gros qu'il faut que l'on soit en mesure de garantir un temps de reaction a une action specifique quelque soit le contexte.
En ce sens, pour faire de la programmation temps reel, il faut imperativement un systeme d'exploitation temps reel (windows ne l'est pas, certains linux s'en approchent) et des applications concues pour.
En ce sens, le java n'est absolument pas temps reel car il est impossible de garantir le temps d'execution d'une routine et ce notament a cause de la machine virtuelle et de son garbage collector.
 
Seulement voila, depuis quelques temps, j'ai entendu de nombreuses personnes issues de societes de service me parler 'temps reel' pour du java ou autre... En fait pour de nombreuses personnes, 'temps reel' se limite a du multithread/multiprocessus, bref des techniques de simulation de RT.
Comme pour ces personnes ca semble est une definition courrante, j'admet qu'on utilise ca aussi. En ce sens donc, Java est 'presque' temps reel. J'imagine que c'est de cette approche que EExtasEE nous parlait.
 
Maintenant, si on reste rigoureux c'est nraynaud qui avait juste...

ce qui aide à confirmer des généralités sur ces gens là

 
Point de vue industrielle, une application est temps reel quand elle garantie que tous les traitements d'entrée sont pris suffisement rapidement en compte pour avoir du sens, et que les resultats de sortie sont aussi calculés suffisament rapidement pour avoir du sens.
 
Apres, le "suffisament" est a definir suivant les contraintes du projet.
A priori on peut faire du temps reel avec Java, mais il ne faudra pas esperer pouvoir placer des contraintes tres fortes.  
 
nota: ca peut en effet dependre de la VM, et de l'algo du Garbage Collector.

pourquoi j'ai un drapeau bleu sur ce topic ?