java threads

[jokertoxic]

hallo,

ik heb een vraag i.v.m. threads in java:
ik zie namelijk niet in dat threads simultaan zijn, ik heb in het boek "java threads" van O' Reilly gelezen.
in het boek gaven ze een voorbeeld van een text-editor met een autosave mogelijkheid
zo stond er dat de gebruiker ongestoord zou kunnen blijven verdertypen terwijl de text-editor opslaat.

maar volgens mij kan dat toch niet, kijk maar is naar de figuur die ik gemaakt heb:

onderaan stellen de 2 rechthoeken mijn programma voor.
links is het hoofdprogramma, met de code in voor het inlezen van de letters die de gebruiker intypt via het toetsenbord.
rechts is de thread om periodiek het bestand te gaan opslaan op de harde schijf.

nu stel dat het programma ingesteld is elke 3 min te gaan opslaan.
de gebruiker start het programma en begint met typen, tot hiertoe is er nog geen probleem de gebruiker kan rustig doortypen want het hoofdprogramma heeft de cpu helemaal voor zichzelf zie groene pijl.
maar als de eerste 3 min voorbij zijn treed de save thread in actie, hierdoor word het hoofdprogramma even onderbroken om zodat de save thread de cpu kan bemachtigen zie oranje pijl

kan iemand mij uitleggen waar ik verkeerd ben?

Alvast bedankt!

 

[kenikavanbis]

OP Zich maakt het zich niet warm.
Moet je weten de meeste computers hebben dual core.Maar weet als je threads wil een save maken moet het serialiseble zijn
wil zeggen dat alles serieel na elkaar gebeurt. autosave zal een momentopname doen en je kan verderwerken maar hier zit je dan wel met het operatingsysteem ook zo heb je windows met his befaamde taakverdeler cheadle wat hem niet in staat stelt deftig met streams over weg te kunnen.maar je hebt dan ook als er veel programmas openstaan ook selectief data verwerken.

Het is als een bureau als er veel op ligt vindt je het dossier trager of als er maar 1 dossier op ligt.

 

[jokertoxic]

ok, vervangen we het autosaven door een muziekje dat op de achtergrond afspeelt terwijl je je brief aan het typen bent.
dan zal je daar toch last van ondervinden?

als de thread waarin het muziekje word afgespeeld uitgevoerd word door de cpu dan kan de cpu toch niet meer inlezen van het toetsenbord en omgekeerd geld hetzelfde terwijl de cpu inleest wat jij aan het typen bent dan zal je toch geen muziekje meer horen?

 

[city guy]

... in het kort komt het antwoord hierop neer:

de CPU leest niets direct. De nodige input verwerking wordt gebufferd. Er wordt een interruptvlag aangezet waarop de interruptcontroller een seintje geeft aan de CPU dat er iets moet gebeuren. Het interrupt wordt afgehandeld: de opdracht is verwerkt. En tenzij je in staat bent sneller dan duizendsten van microseconden snel te typen of te luisteren, dan wel te kijken of een schijfactie uit te voeren, je merkt er als mens niets van.

 

[jokertoxic]

... in het kort komt het antwoord hierop neer:

de CPU leest niets direct. De nodige input verwerking wordt gebufferd. Er wordt een interruptvlag aangezet waarop de interruptcontroller een seintje geeft aan de CPU dat er iets moet gebeuren. Het interrupt wordt afgehandeld: de opdracht is verwerkt. En tenzij je in staat bent sneller dan duizendsten van microseconden snel te typen of te luisteren, dan wel te kijken of een schijfactie uit te voeren, je merkt er als mens niets van.

als ik het dus goed begrijp word er altijd een stukje informatie in een buffer geplaatst en dan uitgevoerd door de cpu?
die informatie wordt dan uitgevoerd wanneer de thread niet in actie is?

 

[city guy]

in je machine lopen soms tientallen processen, threads, programma''s. die krijgen allemaal een beetje tijd (task-switching). De snelheid waarmee taken afgehandeld worden hangt af van het stukje hardware dat gebruikt wordt en de prioriteit in het systeem. We spreken hier dan wel op het meest basale niveau, machinecode, registers, buffers e.d. Waar niet meer vasn Java Html of wat dan ook gesproken wordt; mensen vergaan tot stof, programma's tot binaire instructies.

 

[jokertoxic]

kijk ik heb op internet een voorbeeld gevonden van threads, maar ik snap het niet helemaal zo.

zo ziet het eruit als je het programma opstart:

het is een heel eenvoudig programma, je hebt een startknop en stopknop als je op de startknop drukt dan word een for-lus gestart dat van 1 tot 100000 gaat tellen en drukt die cijfers af in een texkfield.

wat ze in dit voorbeeld hebben gedaan is de for-lus in aparte thread gestoken om 2 redenen zogenaamd
1. zodat de teller kan onderbroken worden wanneer je op de stopknop drukt.
2. zodat het textfield word upgedate met de nieuwe waarde, m.a.w. je ziet de cijfers in het textfield heel snel voorbij flikkeren.

de eerste reden vind ik logisch, doordat java druk bezig is met de for-lus uit te voeren zou je niet meer kunnen klikken op de stopknop.

maar de tweede reden vind ik al minder logisch, veronderstel nu even dat je het tellertje niet in een aparte thread plaats.
dan heeft dat als gevolg dat je niet op de stopknop zal kunnen drukken tot wanneer het tellen is afgelopen, dit vind ik logisch.
maar dat heeft blijkbaar ook als gevolg dat je de cijfers niet meer ziet voorbij flikkeren in het textfield, hij staat in het begin op 1
en na enkele seconden wachten staat hij op 100000.
en het is dit dat ik niet snap: blijkbaar wordt de setText(" ") methode niet meer constant uitgevoerd?
want ik zie het cijfer in het textfield niet meer meer veranderen behalve dan na die paar seconden.

nochtans staat deze methode aanroep wel in mijn for-lus.

stel jij bent java, als er nu word geklikt op de startknop dan krijg jij een melding van een event, je ziet dat de event van de startknop afkomstig is.
dus je springt meteen naar de actionPerformed(Actionevent evt) methode.
daarin zie je een for-lus die zegt dat je de code in de for-lus 100000 keer moet uitvoeren.
oké zeg je ik zal dat doen dus je begint met de eerste keer in de for-lus te gaan. daar zie je plots de volgende methode
setText(" "+ cijfer) van de klasse JTextField, dus spring je in die methode en voert daar alle instructies uit om het cijfer in het textfield af te printen nadat dit gebeurt is keer je terug en doe je verder met de rest van de for-lus je ziet dat niets meer moet uitgevoerd worden dus je voert de for-lus een tweede keer uit en je doet weer hetzelfde maar dan met het volgende cijfer
je doet dit 100000 keer en stopt dan.

weet iemand hoe dit komt?

dit is de code (met thread):

package threads;

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
   
public class UnresponsiveUI extends JFrame {
   private boolean stop = false;
   private JTextField tfCount;
   private int countValue = 1;
   
   public UnresponsiveUI() {   // constructor
      Container cp = this.getContentPane();
      cp.setLayout(new FlowLayout(FlowLayout.CENTER, 10, 10));
      cp.add(new JLabel("Counter"));
      tfCount = new JTextField("" + countValue, 10);
      tfCount.setEditable(false);
      cp.add(tfCount);
   
      JButton btnStart = new JButton("Start Counting");
      cp.add(btnStart);
      btnStart.addActionListener(new ActionListener() {
          public void actionPerformed(ActionEvent evt) {
             stop = false;
             Thread t = new Thread() {
                public void run() {
                   for (int i = 0; i < 100000; i++) {
                      if (stop) break;
                      tfCount.setText("" + countValue);
                      countValue++;
                   }
                }
             };
             t.start();
          }
       });

      JButton btnStop = new JButton("Stop Counting");
      cp.add(btnStop);
      btnStop.addActionListener(new ActionListener() {
         public void actionPerformed(ActionEvent evt) { stop = true; }
      });
   
      setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
      setTitle("Counter");
      setSize(300, 120);
      setVisible(true);
   }
   
   public static void main(String[] args) {
      new UnresponsiveUI();
   }
}

note: ik heb er is ook een System.out.println(""+countvalue) bij geplaatst, en daar zie je wel de cijfertjes voorbij flitsen...
heeft iemand hier een uitleg voor? :/

 

[city guy]

Hi,

afsluitend:
ik kom terug op de originele vraag,
Hoe een thread afgehandeld wordt en wat allemaal bereikbaar is voor de thread hangt af van hoe hij in JAVA gedefinieerd is (zie een tutorial of uitleg voor gevorderden over de verschillende settings).

Uiteindelijk bepalen het OS. het JAVA-platform en de organisatie op de processor hoe de taak uitgevoerd wordt.

 

[kenikavanbis]

Hi,

afsluitend:
ik kom terug op de originele vraag,
Hoe een thread afgehandeld wordt en wat allemaal bereikbaar is voor de thread hangt af van hoe hij in JAVA gedefinieerd is (zie een tutorial of uitleg voor gevorderden over de verschillende settings).

Uiteindelijk bepalen het OS. het JAVA-platform en de organisatie op de processor hoe de taak uitgevoerd wordt.

Niet volledig juist java beschikt over de mogelijkheid windows weg te drummen en controle te hebben over een deel van de processor.of was toch ooit zo u weet nog de history van seriealize wat ooit veel bugs heeft opgelevert bij deling en andere bewerkingen met waar windows ooit een vuile streek heeft gelevert aan sun java1.3 1997-98 nog ergens

Moet je weten als je ruby installeert merk je het zeer goed dat deze ook één mooi deel van de processor eist. maar dat ter zijde ben ik blij dat veel mensen weten dat niets boven de goede strenge code van java bestaat.En spijtig dat er geen directe communicatie is naar hardware is wat op zich de programmeer code niet aantrekkelijk voor hackers maakt.Dit zal dan hun keuze geweest zijn om bepaalde zaken te bemoeilijken.

 

[city guy]

Niet volledig juist java beschikt over de mogelijkheid windows weg te drummen en controle te hebben over een deel van de processor.of was toch ooit zo u weet nog de history van seriealize wat ooit veel bugs heeft opgelevert bij deling en andere bewerkingen met waar windows ooit een vuile streek heeft gelevert aan sun java1.3 1997-98 nog ergens

Moet je weten als je ruby installeert merk je het zeer goed dat deze ook één mooi deel van de processor eist. maar dat ter zijde ben ik blij dat veel mensen weten dat niets boven de goede strenge code van java bestaat.En spijtig dat er geen directe communicatie is naar hardware is wat op zich de programmeer code niet aantrekkelijk voor hackers maakt.Dit zal dan hun keuze geweest zijn om bepaalde zaken te bemoeilijken.

... ben ik 't allemaal mee eens. Helaas moet er gewerkt worden in de situatie van nu. Ik ken Java alleen vanuit de Linux omgeving, maar dat zal binnen de JAVA-ontwikkelomgeving geen verschil mogen maken. (Dat ga ik uitproberen)

 

[GAB]

Ik vrees dat je Threads als iets veel te moeilijk aan het beschouwen bent als je begint te spreken over CPU verwerking.

Een eenvoudig voorbeeld voor Threads:

Je hebt 2 methoden

a) methode 1 telt tot 1000 en begint dan onmiddellijk terug bij nul

b) methode 2 telt tot 2000 wacht 3 seconden en begint dan terug bij nul


Nu ga je ze beiden koppelen aan een schermpje met hun output (dus 2 schermpjes) en je steekt ze in een programma

methode 1;
methode 2;

Eerst begint methode 1 te tellen en dan methode 2 en dat willen we niet, het moet +/- gelijktijdig gebeuren.

"Ok�" zeg jij nu "ik steek de 2 methodes in 1 methode en per keer dat de lus wordt doorlopen tel ik bij beiden 1 op, als methode 1 dan bij 1000 is gekomen zet ik zijn waarde op nul en als methode 2 dan bij 2000 is pak ik de tijd en bij de volgende loops kijk ik of er 3 seconden zijn verstreken en indien dat waar is zet ik de waarde terug op nul"

Volledig correct! Maar je kan dit ook met 2 Threads die dan onafhankelijk van elkaar methode 1 en methode 2 uitvoeren!

En dan komen we nu bij je vraag... Waarom Threads?

Het bovenstaande voorbeeld is heel eenvoudig maar in het echte programmeren is de situatie wel wat complexer

1) stel er gebeurt een fout in methode 1 en die blokkeert. Waarom zou methode 2 moeten stoppen met werken?
2) stel dat methode 1 is opgebouwd uit processen die lang tijd nodig hebben (bijvoorbeeld zaken inlezen over een netwerk, de CPU kan sneller werken dan je netwerkkaart). Waarom zou methode 2 hierop moeten wachten?
3) In het bovenstaande voorbeeld ga je elke lus vragen of de tijd verstreken is? Waarom zou methode 1 daaraan tijd moeten verliezen?

Threads zorgen ervoor dat zaken los van elkaar verwerkt worden

 

[Skinflowers]

Threads zorgen ervoor dat zaken los van elkaar verwerkt worden

Dit is kern de van het verhaal...

Als je een grafisch java programma hebt zal java voor zorgen dat netjes je scherm wordt bijgewerkt en dat het reageert op user input.. zoals typen van tekst of muiskliks..
Dit doet java allemaal in 1 thread (Event Dispatch Thread). Het is dus belangrijk dat je deze thread niet gaat overbelasten.

Dus als je aan knop een berekening hangt die 10 minuten duurt. kan java 10 minuten niet meer je scherm bijwerken en input verwerken.. het programma bevriest dan voor 10 minuten...

Dit los je op door je berekening in een thread uit te voeren, java kan kan dan je programma bijwerken EN je berekening doen..

Succes.