Ubuntu Suomen keskustelualueet

Ubuntun käyttö => Ohjelmointi, palvelimet ja muu edistyneempi käyttö => Aiheen aloitti: Jere Sumell - 31.05.20 - klo:11.17

Otsikko: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: Jere Sumell - 31.05.20 - klo:11.17
Luin kertauksen vuoksi täsäs ajan kuluksi "Aterioivat Filosofit" -ongelman Wikipediasta, joka on tietojenkäsittelyssä rinnakkaisuuteen liittyvä ongelma, joka on esitetty 1960-luvulla ensimmäisen kerran.

Onko palstalaisilla jollakulla koklemusta ohjelmistopatenteista? Ainakin istuva tasavallan presidentti Sauli Niinistö on puhunut joskus EU-tasolla niiden puolesta, että tietokone-ohjelman tai algoritminkin voisi patentoida. Itselleni tuli Helsingin solukämppä vuosinani, kun Sale haki ensimmäisen kerran valtuutusta presidentin töihin kansalta, hänen johonkin bileisiinsä kutsu postissa, mutta se ei liity nyt ohjelmistopatenttiin.

Ajattelin, että jos kehittäisi algoritmin, joka estää tuossa rinnakkaisuusongelmassa lukkiutumisen (deadlock) jotenkin yleisellä tasolla, olisiko mahdollista hakea pantettina siihen patentti-ja rekisterikeskukselta?

Katselin tuossa netissä hakukoneella, niin löysin tuollaisen, kuin "Banker's Algorithm", oikein muita ei löytnyt, jota käytetään tuon deadlockin välttämiseen.

Säikeisiin liittyvää ohjelmointia taitaa olla tiedossa?
Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: Jere Sumell - 31.05.20 - klo:11.41
Voisiko joku tästä Testi-Java luokasta sanoa, mikä mättää, kun tulosteessa kerrotaan, että ainoastaan yksi säie on hengissä.
Ohjelmakoodi
Koodia: [Valitse]
import java.util.*;

public class Testi {

private static String[] nimet = {"Jere", "Ilkka","Tino"};
private static ArrayList<Thread> saikeet = new ArrayList<Thread>();

public Testi() {
for (int x=0;x<nimet.length;x++) {
saikeet.add(new Thread(nimet[x]));
}
startThreads();
count();

}

public void startThreads() {
for (int x=0;x<saikeet.size();x++) {
saikeet.get(x).start();

}
}

public void count() {
int alive = 0;

for (int x=0;x<saikeet.size();x++) {
Thread wT = saikeet.get(x);
if (wT.isAlive()) {
alive++;
System.out.println("Säie nimeltä " +wT.getName()+ " (ID - " +wT.getId() +") on hengissä!");
}
}

System.out.println("Säikeitä kaiken kaikkiaan olemassa: " +saikeet.size() + ", joista elossa: " +alive +" ja kuolleita: " +(saikeet.size()-alive));
}
public static void main (String[] args) {
Testi app = new Testi();

}
}

Ohjelman kun ajaa konsolissa, tuloste on seuraava, joka kertoo, että noita kahta säiettä ei ole käynnistetty ollenkaan, jotka kosntruktorissa käynnistetään. En löydä virhettä koodista. Voisiko joku auttaa?

Tuloste ohjelmaa ajettaessa:
Koodia: [Valitse]
Säie nimeltä Jere (ID - 10) on hengissä!
Säikeitä kaiken kaikkiaan olemassa: 3, joista elossa: 1 ja kuolleita: 2
Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: nm - 31.05.20 - klo:13.55
En nyt pääse kokeilemaan koneella, mutta veikkaan, että muut säikeet eivät ole ehtineet käynnistyä siinä vaiheessa, kun count-metodia kutsutaan.
Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: _Pete_ - 31.05.20 - klo:19.40
Vaikka Thread:t on luotu ja käynnistetty ne eivät ikinä tee mitään koska niiden run() metodia ei ole määritelty/ylikirjoitettu.
Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: Jere Sumell - 01.06.20 - klo:01.14
Aika metkaa. Vaikka run() -metodia ei olekaan ylikirjoitettu, pitäisi mielestäni kaikki säikeet silti olla ajossa tai hengissä, kun tuossa startThreads -metodissa kutsutaan tuota -start() -metodia, joka viittaa kysesen Thread-luokan ilmentymää for-toistosilmukassa . Silti ensimmäisen 0-alkion "Jere" -niminen säie ilmoitetaan ainoastaan elolliseksi, vaikka sekään tee mitään. Eikö kaikki kolme säiettä pitäisi olla tasavertaisia?

Aloitin Java - projektin nimeltä "DeadlockPrevention", ja tämä testi-luokka nyt on lähinnä tutustumisa Java APIn Thread-luokkaan, mutta Githubissa voisi julkaista Banker's Algoritmin Java -esityksen. GeeksforGeeks -sivustolla on ihan havainnollistava esitys tuosta lukkiutumisen välttämisestä.
https://www.geeksforgeeks.org/deadlock-prevention/ (https://www.geeksforgeeks.org/deadlock-prevention/)

Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: Jere Sumell - 01.06.20 - klo:02.25
Vaikka käyttää tuota Thead-luokan run()-metodia sen jälkeen, kun ensin on start() -metodia kutsuttu, tilanne ei muutu miksikään.

Muutin startThreads() -metodin seuraavanlaiseksi
Koodia: [Valitse]
public void startThreads() {
for (int x=0;x<saikeet.size();x++) {
Thread temp = saikeet.get(x);
temp.start();
temp.run();

}
}

En tiedä, jos kokeilisi ohjelmoida oman Säie-tietotyypin kullekin säikeelle, jossa määrittelee tietotyypin otsikkorivissä toteuttamaan Runnable -luokan, ja määrittelee sitten kyseisessä luokassa run() -metodin itse, muuttuuko tilanne miksikään. Sitä kokeilen seuraavaksi.
Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: Jere Sumell - 01.06.20 - klo:02.55
Kokeilin tuota omn saie-luokan määrittelyä, niin nyt tuli ulostulo-tulosteena konsolissa, että kaikki 3 säiettä käynnistyi, mutta 2 elossa, ja yksi kuollut, vaikka missään vaiheessa yhtäkään säiettä ei ohjelmakoodissa eliminoida tai tapeta ajosta.
Koodia: [Valitse]
Säie Jere käynnistyi! (ID - 11)
Säie Ilkka käynnistyi! (ID - 12)
Säie Tino käynnistyi! (ID - 13)
Säikeitä elossa: 2 - Kuolleita: 1

Nyt koodini näyttää seuraavalta:
Koodia: [Valitse]
import java.util.*;

public class Testi  {

private static String[] nimet = {"Jere", "Ilkka","Tino"};
private static ArrayList<FooThread> saikeet = new ArrayList<FooThread>();

public Testi() {
for (int x=0;x<nimet.length;x++) {
saikeet.add(new FooThread(nimet[x]));
}
countActives();
}

public void countActives() {
int active = 0;
FooThread temp = null;
for (int x=0;x<saikeet.size();x++) {
temp = saikeet.get(x);
if (temp.isActive()) {
active++;
}
}
System.out.println("Säikeitä elossa: " +active +" - Kuolleita: " +(saikeet.size()-active));
}

public static void main (String[] args) {
Testi app = new Testi();

}
}

Tuo FooThread -luokka, jossa toteutetaan run-metodi, näyttää seuraavalta:
Koodia: [Valitse]
public class FooThread implements Runnable {

//Properties and Attributes
private static Thread saie;
private boolean active;

//Parameter Constructor
public FooThread(String name) {
this.saie = new Thread(name);
this.saie.start();
this.run();
}

//implementig run

public void run() {
String name = this.saie.getName();
long id = this.saie.getId();
System.out.println("Säie " +name +" käynnistyi! " +"(ID - " +id +")");
this.active = this.saie.isAlive();
}

//Setters and Getters
public boolean isActive() {
return active;
}

public void setActive(boolean active) {
this.active = active;
}

}

Tämä perusteet tästä säie-ohjelmoinnista pitäisi mennä jakeluuni ennen, kuin alkaa jotain järkevää ohjelmointia suunnittelemaan näiden säikeiden käsittelyn ympärille. Vieläkin tässä jokin mättää.
Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: Jere Sumell - 01.06.20 - klo:03.23
Menee nyt vähän norsunluu-tutkimukseksi, mutta sekin kävi mielessä, että missä vaiheessa Javan roskienkeruu-operaatio (Garbage Collector) mahtaa poistaa noita säikeitä muistista onkohan se heti kun säikeen toiminta on päättynyt. Javan anatomiasta niin paljon tietoa.

Jos ajatellaan, että ohjelmoidaan jotain pankkijärjestelmää, ja jos sen pankki-transaktion ajattelee säikeenä, esim. tilisiirto "Ilkka tekee 50 euron tilisiirron Jerelle", niin ensin tarkistetaan Ilkan tilin saldo, ja jos kate on kunnossa, sieltä vähennetään 50, ja sitten lisätään Jeren saldoon 50. Pankeillakin on vuorokaudessa tuhansia tilisiirtoja, niin pitää olla joku järjestelmä, missä hallinnoidaan muistiresursseja ja nopeuskin on aika kriittinen arvo.

Onkohan jossain ohjelmointikielessä sisäänrakennettuna jonkinlaista resurssien hallinnointimekanismia vähän tuon Javan roskienkeruun tapaan. Periaatteessa välimuistista voi poistaa sitten tuon tilisiirto-transaktion tiedon sen jälkeen, kun finanssidata on tupattu tietokantaan, sen jälkeen tiedot on saatavilla sieltä, niin välimuistissa niitä ei välttämättä tarvitse säilyttää enää.

Ennen koronaa tietokanta-kurssilla jonkin verran puuhasin JSON-datan tuottamiseen liittyvän ohjelmakoodin  parissa sen tuppaamiseen SQL-tietokantaan, käytin org.JSON-kirjastoa, jonka saa ladattua osoitteesta https://jar-download.com/artifacts/org.json (https://jar-download.com/artifacts/org.json) niin siinäkin olisi jouten aikaa jos on, niin sovellskehityksen paikka, joka HTML-lomakkeen tiedot tuppaa JSON-muodossa tietokantaan.
Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: _Pete_ - 01.06.20 - klo:08.21
Tämä perusteet tästä säie-ohjelmoinnista pitäisi mennä jakeluuni ennen, kuin alkaa jotain järkevää ohjelmointia suunnittelemaan näiden säikeiden käsittelyn ympärille. Vieläkin tässä jokin mättää.

Sen lisäksi että perusteet säie-ohjelmoinnista on hyvä kerrata ensin myös java/oo-ohjelmoinnin perusteet mitä tarkoittaa perintä ja sen suhteen mikä ero on luokka- ja instanssi muuttujalla, nyt tuossa FooThread luokassa niitä on oudolla tapaa käytetty:

    private static Thread saie;


Lisäksi koska FooThread itse jo toteuttaa Runnablen (= säie) ei sen sisällä tarvitse luoda turhaa Threadia ja käynnistää sitä tekemään saman ei mitään kuin alkuperäisessa versiossa.

Sitten on harhaanjohtavaa "yli kirjoittaa" metodeita eri nimellä niin että niiden käytöstä saa väärän kuvan. Voi ihan suoraan kutsua FooThread instanssin isAlive() metodia sen sijaan että kutsuisi isActive(). active/alive ovat eri asioita eikä niitä kuulu tuolla tapaa nimetä väärin ja sotkea.

Nyt tuo toteutus ei aja omana säikeenä ollenkaan FooThread luokan instansseja vaan:

1) Luodaan FooThread instanssi

2) Tämän constructorissa luodaan turha säie joka käynnistetään ja ei tee mitään

3) Kutsutaan constructorissa luodun instanssin run() metodia.

Tämä kaikki tapahtuu ohjelman main-thread toimesta.

Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: Jere Sumell - 02.06.20 - klo:08.02
Joo, no toi static -avainsana rikkoo tiedon kapselointi-periaatetta tietotyyppiä määrittäessä. Lisäksi turvallisuusriski, kun staattisiin attribuutteihin pääsee käsiksi suoraan ulkopuoliset ja arvot voi sitten olla mitä on.

Ehkä tuossa kesäyön hämärinä tunteina viihteellä kun olin aiemmin illalla, niin aivot ihan maksimiteholla pyörinyt koodin tuottamisen suhteen. On tosiaan valuvirhe tuossa koodissa monta seikkaa.

Tuossa avauksessa, kun tiedustelin, että onko jollakulla foorumilaisella ohjelmistopatenteista kokemusta, niin lähetin kysymyksen siitä Patentti-ja rekisterihallitukselle, niin sieltä tuli ystävällisin terveisin vastaus, että vaikka Suomessa on ohjelmistopatentti mahdollinen, niin jonkin yksittäisen algoritmin patentointi on kaksipiippuinen asia, kyllä ja ei oli vastaus, esimerkiksi jotain matemaattista ongelmaa ratkaiseva algoritmi ei ole patentoitavissa, vaan algoritmin pitää liittyä jonkin konkreettisen järjestelmän toimintaan edesauttavasti, tai pitää esittää patenttihakemuksessa tarkka kuvaus tai ainakin siihen tulisi liittää se toiseen koneeseen esimerkiksi tietokoneeseen liitettynä.

Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: Jere Sumell - 02.06.20 - klo:08.30
Vielä tuosta patentista lisenssoinnista, että järkevin 1-2 miehen IT-talon liiketoiminta-malli lienee se, jos sattuu johonkin ohjelmointiongelmaan jollain sektorilla kehittämään jotain uutta, mikä on erittäin haastavaa esimerkiksi joskus vuosikymmeniä sitten esitettyyn ohjelmointiongelmaan, niin perustaa osakeyhtiön, joka hallinnoi sitä patenttia, eikä tarvitse lähteä koko järjestelmää myymään.

Vaikka pystyisi toimittamaan jonkin järjestelmän, niin ongelmia tulee siinä, kun työkokemukseni on lähinnä julkisen sektorin hallinto ja koulutuspuolelta, kun esimerkiksi Turun kaupunki päättää investoida johonkin uuteen tietojärjestelmään, järjestelmäntoimittaja kilpailutetaan, ja lain mukaan se tarjouskilpailu on tosin avoin ja julkinen, mutta kokemus osoittaa, mitä olen tuota hallintosekoilua seurannut, niin pienillä toimijoilla ole mitään jakoa saada sitä toimitussopimusta. Yleensä päätös on se, että edullisin valitaan, ja isot ohjelmisto/järjestelmätoimittajat pystyvät tarjoamaan koko tietojärjestelmän elinkaaren ja niillä on jo aiempia referenssejä, niin helposti ymmärrettävissä, että valinta kohdistuu sellaisiin toimijoihin. Tästäkin on puhuttu, mitä olen vasemmistoliiton pienyrittäjätyöryhmässä jäsenenä nyt vuonna 2020, että tähän pienten toimijoiden jonkinlaiseen sortamiseen tulisi jotain muutosta tapahtua.

Tuollaisessa liiketoimintamallissa, missä hallinnoidaan sitä ohjelmistopatenttia, patentin haku ja ylläpitäminen maksaa jotain rahaa, ja sitten palkataan asianajaja, joka ymmärtää lisenssisopimuksien lakitaustan, se maksaa, ja tulot muodostuu sitten noista lisenssimaksuista tai sitten yritys pyörii niin kauan tappiollisena, että joku on kiinnostunut siitä patentista niin paljon joku isompi toimija, että on kiinnostunut ostamaan yrityksen ulos markkinoilta, kun patentti tuottaa lisäarvoa yritykselle, niin alkuperäinen perustaja nettoaa sitten yrityskaupoista jonkun miljoonan, kun kaupan hinta on sitten niin suuri, että se kattaa kaikki aiemmat kustannukset ja sitten pitäisi saada vielä voita leivän päälle joksikin aikaa, niin ei sitä millään eurolla kahdella myydä sitten tietenkään kenellekään.

Tetriksestä, kun pidän, sehän on hyvä esimerkki, kun Tetris Holding Companylla, jossa on yhtenä perustajana ollut Tetriksen alkuperäinen venäläinen tietokoneinsinööri, niin yhtiöllähän on Tetris-algoritmi-patentti Yhdysvalloissa, ja juuri eilen luin artikkelin netistä, että 15 vuotta takaperin eräs mobiilipepeljä valmistava yritys oli maksanut Tetris-lisenssistä 135 miljoonaa taalaa, ja se kattoi seuraavat 15 vuotta kaikki Tetris Holding Companyn Tetris-oikeudet, mitä yritys hallinnoi. Tetriksestä kannattaa pitää.
Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: Jere Sumell - 02.06.20 - klo:08.48
Tämä perusteet tästä säie-ohjelmoinnista pitäisi mennä jakeluuni ennen, kuin alkaa jotain järkevää ohjelmointia suunnittelemaan näiden säikeiden käsittelyn ympärille. Vieläkin tässä jokin mättää.

Sen lisäksi että perusteet säie-ohjelmoinnista on hyvä kerrata ensin myös java/oo-ohjelmoinnin perusteet mitä tarkoittaa perintä ja sen suhteen mikä ero on luokka- ja instanssi muuttujalla, nyt tuossa FooThread luokassa niitä on oudolla tapaa käytetty:

    private static Thread saie;


Lisäksi koska FooThread itse jo toteuttaa Runnablen (= säie) ei sen sisällä tarvitse luoda turhaa Threadia ja käynnistää sitä tekemään saman ei mitään kuin alkuperäisessa versiossa.

Sitten on harhaanjohtavaa "yli kirjoittaa" metodeita eri nimellä niin että niiden käytöstä saa väärän kuvan. Voi ihan suoraan kutsua FooThread instanssin isAlive() metodia sen sijaan että kutsuisi isActive(). active/alive ovat eri asioita eikä niitä kuulu tuolla tapaa nimetä väärin ja sotkea.

Nyt tuo toteutus ei aja omana säikeenä ollenkaan FooThread luokan instansseja vaan:

1) Luodaan FooThread instanssi

2) Tämän constructorissa luodaan turha säie joka käynnistetään ja ei tee mitään

3) Kutsutaan constructorissa luodun instanssin run() metodia.

Tämä kaikki tapahtuu ohjelman main-thread toimesta.

Tein muutoksia koodiin, ja nyt siinä pitäisi olla mitään epäselvää ja nyt FooThread -luokkakin toteuttaa tiedon kapselointi -periaatetta (Data Encapsulation). tosin toString() -metodia ei ole ylikirjoitettu, vaikka tavallisesti se pitäisi kai ylikirjoittaa.

Nimesin TestiB--luokaksi yksinkertaistetun -version, ja se näyttää nyt tältä:
Koodia: [Valitse]
import java.util.*;

public class TestiB  {

private static String[] nimet = {"Jere", "Ilkka","Tino"};
private static ArrayList<FooThread> saikeet = new ArrayList<FooThread>();

public TestiB() {
for (int x=0;x<nimet.length;x++) {
saikeet.add(new FooThread(nimet[x]));
}
countActives();
}

public void countActives() {
int active = 0;
FooThread temp = null;
for (int x=0;x<saikeet.size();x++) {
temp = saikeet.get(x);
if (temp.getSaie().isAlive()) {
active++;
}
}
System.out.println("Säikeitä elossa: " +active +" - Kuolleita: " +(saikeet.size()-active));
}

public static void main (String[] args) {
Testi app = new Testi();

}
}

FooThread -luokkaa yksinkertaistin, ja poistin tuon run()-metodin luokassa toteuttamisen, ja poistin Thread -tyyppisen säie-luokan attribuutin staattisesta tavalliseksi luokkaattribuutiksi. Tosiaan Thread-luokkahan, kuten totesit, toteuttaa tuon run()-metodin, ja siihen pääsee käsiksi, kun setters/getters -metodeihin lisää tuon Thread-ilmentymän saantimetodin.

Koodia: [Valitse]
public class FooThread  {

//Properties and Attributes
private Thread saie;

//Parameter Constructor
public FooThread(String name) {
this.saie = new Thread(name);
this.saie.start();

}

//Setters and Getters


public Thread getSaie() {
return saie;
}

public void setSaie(Thread saie) {
this.saie = saie;
}
}

Taas avoin kritiikille tässä perus-säie-casessa. Nyt Java- semantiikka on kohdallaan ilman mitään epäselvyyksiä?

Nythän ilman mitään ylimääräisiä sekoiluja kaikki säikeet ovat käynnissä, kuten konsolitulostekin ilmoittaa:
Koodia: [Valitse]
Säie nimeltä Jere (ID - 10) on hengissä!
Säie nimeltä Ilkka (ID - 11) on hengissä!
Säie nimeltä Tino (ID - 12) on hengissä!
Säikeitä kaiken kaikkiaan olemassa: 3, joista elossa: 3 ja kuolleita: 0
Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: _Pete_ - 02.06.20 - klo:09.19
Joo, no toi static -avainsana rikkoo tiedon kapselointi-periaatetta tietotyyppiä määrittäessä. Lisäksi turvallisuusriski, kun staattisiin attribuutteihin pääsee käsiksi suoraan ulkopuoliset ja arvot voi sitten olla mitä on.

static ei liity kapselointiin mitenkään vaan siitä vastaa public/protected määritykset.

Pitää siis selvittää mikä ero on luokka muuttujalla (=static) vs luokan INSTANSSI muuttujalla.
Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: _Pete_ - 02.06.20 - klo:09.30

Taas avoin kritiikille tässä perus-säie-casessa. Nyt Java- semantiikka on kohdallaan ilman mitään epäselvyyksiä?

Nythän ilman mitään ylimääräisiä sekoiluja kaikki säikeet ovat käynnissä, kuten konsolitulostekin ilmoittaa:

Koodia: [Valitse]
Säie nimeltä Jere (ID - 10) on hengissä!
Säie nimeltä Ilkka (ID - 11) on hengissä!
Säie nimeltä Tino (ID - 12) on hengissä!
Säikeitä kaiken kaikkiaan olemassa: 3, joista elossa: 3 ja kuolleita: 0


Uudessa TestiB:ssä edelleen käytetään vanhaa Testi luokkaa.

Ja Threadit eivät vieläkään oikeasti tee mitään. Se että ne näkyy olevan hengissä johtuu siitä että eivät ole ehtineet luonnin - tyhjän run()  kutsumisen jälkeen vielä kuolemaan ja tulleet siivotuksi pois
Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: Jere Sumell - 02.06.20 - klo:09.36
Joo, no se on selvää ollut alusta asti itsellenikin, että mitään ei säikeet tee elossa kituuttelun lisäksi, siinä mielessä tämä Testi-luokan ohjelma on typerä, tiedä mitä arvoa tällä ole mitään muuta, kuin ajankuluksi tutustutaan Thread-luokan perusteisiin.
Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: Jere Sumell - 02.06.20 - klo:09.39

Taas avoin kritiikille tässä perus-säie-casessa. Nyt Java- semantiikka on kohdallaan ilman mitään epäselvyyksiä?

Nythän ilman mitään ylimääräisiä sekoiluja kaikki säikeet ovat käynnissä, kuten konsolitulostekin ilmoittaa:

Koodia: [Valitse]
Säie nimeltä Jere (ID - 10) on hengissä!
Säie nimeltä Ilkka (ID - 11) on hengissä!
Säie nimeltä Tino (ID - 12) on hengissä!
Säikeitä kaiken kaikkiaan olemassa: 3, joista elossa: 3 ja kuolleita: 0


Uudessa TestiB:ssä edelleen käytetään vanhaa Testi luokkaa.

Ja Threadit eivät vieläkään oikeasti tee mitään. Se että ne näkyy olevan hengissä johtuu siitä että eivät ole ehtineet luonnin - tyhjän run()  kutsumisen jälkeen vielä kuolemaan ja tulleet siivotuksi pois

Joo, Sama Testi - luokkahan siinä leikepöydältä pohjaksi tuli copy-pastella. Muutin ainoastaan tuon isActive()-poiston ja lasken vielä hengissä olevat prosessit suoraan tuon Thread-tyyppisen ilmentymän isAlive()-metodia käyttämällä, kuten tässä oli kommentteissa koodistani.
Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: _Pete_ - 02.06.20 - klo:10.48
Joo, Sama Testi - luokkahan siinä leikepöydältä pohjaksi tuli copy-pastella. Muutin ainoastaan tuon isActive()-poiston ja lasken vielä hengissä olevat prosessit suoraan tuon Thread-tyyppisen ilmentymän isAlive()-metodia käyttämällä, kuten tässä oli kommentteissa koodistani.

Sitä juuri tarkoitin että on sellainen copy/paste tyylinen ratkaisu joka sattuu toimimaan vahingossa. TestiB luokan main() luodaan instanssi vanhasta Testi luokasta ja sen koodi suoritetaan eikä ollenkaan TestiB luokan koodia.

Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: Jere Sumell - 02.06.20 - klo:12.16
Joo, Sama Testi - luokkahan siinä leikepöydältä pohjaksi tuli copy-pastella. Muutin ainoastaan tuon isActive()-poiston ja lasken vielä hengissä olevat prosessit suoraan tuon Thread-tyyppisen ilmentymän isAlive()-metodia käyttämällä, kuten tässä oli kommentteissa koodistani.

Sitä juuri tarkoitin että on sellainen copy/paste tyylinen ratkaisu joka sattuu toimimaan vahingossa. TestiB luokan main() luodaan instanssi vanhasta Testi luokasta ja sen koodi suoritetaan eikä ollenkaan TestiB luokan koodia.

Hyvä "_Pete", että olet tarkka, sattumalta meni ohi itseltä tuo. Pitäisi luoda TestiB -ilmentymä. Korjasin koodin, ja ohjelma toimii oikein, vaikka ei mitään järkevää säikeiden toimintaan olekaan ohjelmoitu.

Koodia: [Valitse]
Kaikkien säikeiden lukumäärä 3 Säikeitä elossa: 3 - Kuolleita: 0

Lopullinen TestiB-koodi

Koodia: [Valitse]
import java.util.*;

public class TestiB  {

private static String[] nimet = {"Jere", "Ilkka","Tino"};
private static ArrayList<FooThread> saikeet = new ArrayList<FooThread>();

public TestiB() {
for (int x=0;x<nimet.length;x++) {
saikeet.add(new FooThread(nimet[x]));
}
countActives();
}

public void countActives() {
int active = 0;
FooThread temp = null;
for (int x=0;x<saikeet.size();x++) {
temp = saikeet.get(x);
if (temp.getSaie().isAlive()) {
active++;
}
}
System.out.println("Kaikkien säikeiden lukumäärä " +saikeet.size() +" Säikeitä elossa: " +active +" - Kuolleita: " +(saikeet.size()-active));
}

public static void main (String[] args) {
TestiB app = new TestiB();

}
}

Tietokoneissa mikään toimi vahingossa tai ainakaan ilman, miten ohjelmoija on määritellyt koodiin. Nyt tässä esimerkissä ei ole vanhgossa toimivuuden ikeetä, josta päätyisi jalkapuuhun tai hirteen.
Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: AimoE - 02.06.20 - klo:19.19
Tässä minun käsitykseni patenteista:

Pienyritys tarvitsee patenttia suojatakseen sijoitusta, joka tarvitaan teollisen valmistuksen käynnistämiseen ja markkinoille pääsyyn. Kun tuotanto pyörii ja kauppa käy, patentin ylläpitoon ei enää kannata panostaa. Isossa yrityksessä mukana on muitakin motiiveja. Ison patenttisalkun avulla voidaan pelata nokkapokkaa eli uhitella, diivailla ja käydä kauppaa kilpailijoiden kanssa. Ja kun vakuutusmatematiikkaa muistuttavalla menetelmällä lasketaan millä palkkasummalla minkäkin suuruinen t&k-henkilöstö pystyy tuottamaan kilpailukykyä, yhtenä henkilöstön mittarina tässä laskennassa käytetään osakesalkkua.

Yksityiselle ihmiselle patentti on arvokas vain jos joku muu on valmis maksamaan patentista suojatakseen sijoituksia valmistukseen.

Jos keksintö ei koske valmistusta, ei ole mitään syytä olettaa että kukaan maksaisi keksinnöstä patenttimaksuja. Tekijänoikeusmaksuja voi kyllä odottaa, mutta patentti on mielekäs vain valmistuksen yhteydessä. Jos keksit mielestäsi hienon algoritmin, voit yrittää vaatia koodistasi tekijänoikeusmaksua. Jos keksit mielestäsi hienon tavan valmistaa jotain tuotetta tai tehostaa jotakin valmistuksen yksityiskohtaa siten, että valmistus on helpompaa ja halvempaa tai valmistettava tuote on jotenkin parempi kuin mikän muu, voit yrittää rekisteröidä patentin.

Keksintö joka perustuu puhtaasti ohjelmakoodiin on aina matematiikkaa, eikä matematiikka Euroopasa voi patentoida.
Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: Jere Sumell - 02.06.20 - klo:19.35
Olen tänään vähän käyttänyt aikaa säikeiden parissa työskentelyyn.

Pistin Dropboxiin jakoon päivän tuotokseni pienen pankkisimulaattorin, jossa lähestymistapana on asiakkaan ja pankkitransaktion käsittäminen säikeenä.
Readme-tiedostossa tarkemmat kuvaukset.

Suora linkki Dropbox-jakooni on
https://www.dropbox.com/sh/njgchl6ym67sqwc/AAAygWRXRcHw-1d8VJ9xASmQa?dl=0 (https://www.dropbox.com/sh/njgchl6ym67sqwc/AAAygWRXRcHw-1d8VJ9xASmQa?dl=0)
Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: Jere Sumell - 02.06.20 - klo:20.44
En ole yhtään juovuksissa päivän ohjelmoinnista tämän postauksen yhteydessä.

Jos Suomessa ei olisi rahapeli-monopolia Veikkauksella, varmaan päätyisin hakemaan rahapeli-toimintalupaa ja perustaisin "Euronklikit", kun näyttää ihan julkisessa netissäkin olevan kaikki "Euronklikit" -osoitteet vapaana, ja modifioi vähän tuota pankki-simulaattori-koodiani, ja pistää etusivulle alkuvaiheessa houkuttimeksi sen, että näyttäisi että jotain toimintaa sivulla on, ja Kolikonheitto pelinä. Jos tarjoaa joko kruunalle tai klaavalle kerrointa 2.10, ja kolikkoa heitettäessä on pieni todennäköisyys, että kolikko päätyy pystyyn, talo voittaa siinä tapauksessa, muutoin pelaaja oikein veikattuaan voittaa 2.10 kertaisena rahat takaisin. Euroklikki tulee siitä, että panos olisi vakio aina 1 euro, eikä järjestelmää sallita. Se on joko tai.

Ajan mittaan Suomi on niin pelihullua kansaa, että näennäistoimintaa, kun pyörittää jonkun aikaa, ennen pitkää löytyy joku, ketä maksaa esim. Paypal-sijoituksella yhden euron siinä toivossa, että saa tuplattua rahat.

Olen ihmisten asialla, eikä ketään saa huijata, mutta jos palautusprosentin ja tuon kolikon lappeelle jäännin mahdollisuuden tarjoaa talon etuna, tommosen Euronklikit-kolikonheitto-pelin pystyisi aika pienellä alkupääomalla pistämään siten pystyyn, että pitkässä juoksussa talo voittaa lopulta kaikkien pelaajien rahat ilman, että pelinjärjestäjä menee konkurssiin, mitä olen simuloinut Java-ohjelmallani. Olettaen tietenkin, että ainut panosvaihtoehto 1 euro pysyy vakiona joka kolikonheitto-panostuksessa.

En tosissani ole toimimassa tosin ihmisten rahoja vieden huijaamalla uhkapeliin tai yllyttämällä, enkä halua edesauttaa kenekään ryhtyvän moiseen. Ei ole kestävän kehityksen edesauttamisen positiivisessa mielessä kuuluva filosofiaani, mutta teoriassahan kaikkea voi esittää.
Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: _Pete_ - 02.06.20 - klo:21.30

Suora linkki Dropbox-jakooni on
https://www.dropbox.com/sh/njgchl6ym67sqwc/AAAygWRXRcHw-1d8VJ9xASmQa?dl=0 (https://www.dropbox.com/sh/njgchl6ym67sqwc/AAAygWRXRcHw-1d8VJ9xASmQa?dl=0)

Olet tässäkin keksinyt pistää pariin kohtaan turhaan threadin joka käynnistyessään ei tee mitään ja siis on tämän ohjelman toiminnan kannalta ihan turha. Transaktiot eivät ole sama asia kun Thread. Niiden tarkoitus on suojata käytettyjä resursseja niin että yhtä resurssia ei voi muuttaa transaktion aikana muualta ja tarvittaessa kaikki transaktion sisällä tehdyt resurssien muutokset ja voidaan palauttaa tilaan joka oli ennen transaktion alkua.

Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: Jere Sumell - 02.06.20 - klo:21.48
Totta puhut. En ole finanssitekniikan ja pankkimaailman ykkösmiehiä edes. On totta, että kaikkia säikeitä ei käsitellä tuossa luokkakokonaisuudessa, jonka jaoin tuolla Dropboxissa. Onpahan nyt jokin ajankulutus-ratto ollut tänään, kun ei ole oikein muutakaan ollut.
Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: Jere Sumell - 13.06.20 - klo:10.15

Ennen koronaa tietokanta-kurssilla jonkin verran puuhasin JSON-datan tuottamiseen liittyvän ohjelmakoodin  parissa sen tuppaamiseen SQL-tietokantaan, käytin org.JSON-kirjastoa, jonka saa ladattua osoitteesta https://jar-download.com/artifacts/org.json (https://jar-download.com/artifacts/org.json) niin siinäkin olisi jouten aikaa jos on, niin sovellskehityksen paikka, joka HTML-lomakkeen tiedot tuppaa JSON-muodossa tietokantaan.

Tuollaisen verkkopalvelun ohjelmointi, jos luppoaikaa on, joka tarjoaa web-käyttöliittymän SQL-tietokannan luontikoodin generointiin käyttäjän lomakesyötteiden pohjalta, ei Javalla kannata melkein lähteä toteuttamaan. Mitän olen Pythonin Djangoa tässä kertaillut kesäpäivien ajan kuluksi, backendin voisi kätevämmin ehkä toteuttaa Pythonilla.

Googlasin parsereita, jotka muuntaa JSON-formaatista SQL-tietokannan luontikoodin, niitäkin löytyy netistä jonkin verran vaihtelevalla menestyksellä toimivia, ja varmaan löytyy jo tuollaisiakin aputyökaluja ohjelmoijien mielenterveyden säästämisen edistämiseksi, joka tarjoaisi helpon graafisen web-käyttöliittymän, jonka parametrien pohjalta sitten tulosteena olisi .sql -tiedosto, joka sisältää käyttäjän tietokannan luontikoodin.
Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: jekku - 13.06.20 - klo:10.37
Kuulostaa huimalta, suorastaan monimutkaiselta?

Kun kannan luonti lienee kertakeikka.
Kun minulle tuli tuollainen vastaan niin spekseistä (eli tilaajan toivomuksista) kokosin tarvittavat askelmerkit, ja sitten ihan uniikki luontiskripti.

Ja skriptikin vain sen takia että jäipä jonkinsortin dokumentaatio ;)

No, jos kyse vain kannan luonnista niin ei siinä kai mitään konstikasta, mutta yleensä siihen liittyi kokoelma tauluja, käyttäjiä, käyttäjien oikeuksia jne.
Otsikko: Vs: Rinnakkaisuusongelmaan liittyvä lukkiutumisen esto-algoritmistä
Kirjoitti: Jere Sumell - 14.06.20 - klo:17.51
Googlasin tuosta aiheesta, jonka esitin viimeismpänä "Database Schema Creation Tool", tai vastaavalla hakutermillä, ja löysin muutamia kaupallisia yrityksiä, jotka tarjoavat kalliita lisenssejä web-sovelluksiinsa, jotka luovat noita skriptejä. Graafisia ER-mallinnus-työkaluja on pilvin pimein, osa niistäkin maksullisia, mutta harvassa, DIA:ssakaan, joka tosin ei ole verkkopohjainen sovellus, vaan Standalone, DIA:kaan ei sisällä ominaisuutta generoida tietokannan metadatasta tietokantaan ajettavaa .sql-tiedostoa.

Windows-ympäristössä Turun AMK:n Tietokannan suunnittelukurssilla käytettiin muistaakseni Rise -nimistä työkalua, joka sisältää graafisen käyttöliittymän ER-mallinnukseen, ja sitten http://www.risetobloome.com/Page_1_S_NoPadding.aspx?item=530 (http://www.risetobloome.com/Page_1_S_NoPadding.aspx?item=530) valmistajan sivuilta saa myös ladattua noita koodigeneraattoreita, jotka luo tuon ER-mallin pohjalta jonkinlaisen kooditiedoston, jonka voi ajaa sitten terminaalista tietokantaan. Tosin lopputulos oli Postgres -kannan luodun koodin osalta sekava, ja ilman dokumentointia.

Jos nyt lähinnä tarkentaisin, että ER-mallista SQL-Database Schema (en tarkalleen ottaen tiedä tuota Scheman tietotekniikan yhteydessä käytettävää suomennosta, mutta psykologiassa se on Skeema, sisäinen malli, olen kuullut tuon tietotekniikka-kontekstiin liitettynä joskus, mutta se on unohtunut, koska sitä tule koskaan suomeksi näitä termejä käytetyksi) koodin SQL-scheman (Tietokannan Metadata) koodiluonti -generaattori -sovellus, jos helpottaa vähän, siihenhän ei näitä käyttöoikeuksien määritystä sisällytetä.

Tosiaan voisi mennä ehkä liian kompleksiseksi, jos ajattelee tietokannan ylläpitäjän (Database Administrator ) osalta kompleksiseksi mitään automatisoitua metadatan luonti-casea hoitaa? Mutta ohjelmistokehittäjät eivät tavallisesti hoida noita Adminin tehtäviä, ainoastaan hoitavat tilauksesta tietokannan suunnittelun ja määrittelyn. Ajattelen siis ohjelmistokehitys-firman kautta tätä asiaa. Tietokannan tilaava yritys palkka jonkin pää-käyttäjän tietokannalle, jonka työtehtävä sitten hoitaa nuo käyttäjäoikeus-määrittelyt.

Googlaa tuolla aloittamallani hakutermillä, ja hämmästy, miten voisi "Valmistettu Suomessa" -logon jos hakee, ensimmäisenä kotimaisena tarjoajana tarjota kotimaisen palvelun ohjelmistoyritysten työkaluksi. Jos tuotteen kaupallistaa, ja markkinoi sitä järkevällä tavalla, koska kuitenkin tuotteen kanssa täytyy jossain olla esillä, että potentiaaliset asiakkaat löytävät sen, voi olla, että se saisi jonkinlaista menestystä.

Sitten jos vielä haluaa kompleksisemman haasteen, jos on nörtti, joka hallitsee tietokannat jo syntymästä saakka täydellisesti, voi alkaa suunnittelemaan omaa Tietokantahallintajärjestelmää -koko paketti haltuun, RDBMS -markkinat ja niche haltuun sitten, kun on kaupallinen koulutus tietokoneinsinöörin tohtoritutkinnon jälkeen. Lolz.