Avatar billede tula Nybegynder
24. maj 2004 - 16:36 Der er 12 kommentarer

Vil en uendeligt metode-kald belaste mit system.

Hej!

Jeg er ved at lave et interface mellem min seriel port og mit java-program. I mit interface laver jeg et konstant kald til en metode, der læser fra seriel porten. Det er så at sige en uendelig løkke, jeg har lavet. Jeg vil høre, om det er belastende for systemet at kalde denne metode hele tiden og om der eventuelt er en bedre måde at gøre det på? Her er metoden:

public String readLine()
  {
    String line=null;
    try
    {
      line=in.readLine();
      System.out.println(line);
    }
    catch( IOException e )
    {
      error("readLine " + e );
    }
    readLine();

    return(line);

  }
Avatar billede razor Nybegynder
24. maj 2004 - 16:39 #1
Det virker lidt vildt at lave en rekursiv løkke for det:

public String read() {
  String line = null;
  while(true) {
    try {
      line = in.readLine();
      System.out.println(line);
    } catch( IOException e ) {
      error("readLine " + e );
    }
  }
}
Avatar billede jpvj Nybegynder
24. maj 2004 - 16:39 #2
Ja - det du gør kaldes at "polle", og det vil belaste alle systemer.

En eller anden form for Interrrupt baseret løsning er det eneste rigtige - hvordan det lige laves med en serielport/Java aner jeg ikke.
Avatar billede jpvj Nybegynder
24. maj 2004 - 16:40 #3
razor> He-he - det så jeg slet ikke. Den løsning vil crashe programmet, så jeg er helt enig med dig.
Avatar billede arne_v Ekspert
24. maj 2004 - 16:46 #4
Medmindre in er af en speciel type (ikke java.io) så er readLine
blocking d.v.s. at den venter indtil der er input.

Det betyder minimal belastning på dit system. Men muligvis uhensigtsmæssig
opførsel hvis dit program er single threaded.
Avatar billede arne_v Ekspert
24. maj 2004 - 16:47 #5
(jeg er naturligvis enig i at det rekursive kald ikke skal være der)
Avatar billede tula Nybegynder
24. maj 2004 - 16:53 #6
razor...er det en løsning, som holder, den du skriver?

arne_V...in er af typen BufferedReader fra java.io pakken, det er vel ikke så smart? Kan du stå inde for oventående løsning
Avatar billede arne_v Ekspert
24. maj 2004 - 17:05 #7
Der er ikke noget belastnings problem.

Du skal have fjernet det rekursive kald.

Og jeg ville overveje at fjerne metoden helt. Da jeg ikke rigtigt synes at
den bidrager med noget i forhold til at kalde in.readLine.
Avatar billede tula Nybegynder
24. maj 2004 - 17:10 #8
OK, men jeg behøver vel while-metoden for at lade den løbe!
Avatar billede tula Nybegynder
24. maj 2004 - 17:30 #9
razor...din løsning er vel også rekursiv i en grad, men den belaster måske ikke systemet så kraftigt?
Avatar billede soreno Praktikant
24. maj 2004 - 17:56 #10
Når en metode kaldes lægges der nogle parametre (styres af compileren) på den globale stak (ikke ret mange bytes, sikkert i omegnen af 8-16 bytes pr. metode kald).

Det er først når metoden returnerer at disse parametre fjernes fra stakken.

Så hvis ikke du returnerer i din metode (det gør du ikke i den i dit spørgsmål), så vil stakken stille og roligt blive større og større. På et tidspunkt er der ikke mere ram til processen og så kan du sikkert gætte hvad der så vil ske.

Razor's while løkke laver ikke nogle ekstra variable som puttes på en stak. Derfor vil den ikke løbe tør for ram.
Avatar billede arne_v Ekspert
24. maj 2004 - 22:04 #11
Hvis du virkeligt vil have en uendelig løkke så  skal du jo have
enten while(true) eller for(;;)
Avatar billede tula Nybegynder
25. maj 2004 - 10:55 #12
OK...tak! Jeg har allerede implementeret en løsning med while(true) med inspiration fra razor. Så razor, du får point!
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Kurser inden for grundlæggende programmering

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester