Gå til innhold

Yngve vil at Microsoft skal ligge unna tastaturet hans


Anbefalte innlegg

Gjest Slettet-t8fn5F

Nei, vi er absolutt ikke på atomnivå. Race condition kan inntreffe bare basert på hvordan scheduleren oppfører seg, og det trenger ikke å være på grunn av atomoistisk fysikk (selv om det selvsagt ikke er helt urelevant, men det er en helt annen diskusjon). Og de kan inntreffe rett som det er.

 

Betrakt følgende elementære C++ program:

 

 

#include <iostream>
#include <thread>
#include <vector>
#include <random>

int main(int argc, char **argv) {
  const int number_of_runs_per_thread = 16;
  volatile int counter = 0;
  int number_of_threads = 4;

  if (argc == 2) {
    number_of_threads = std::atoi(argv[1]);
  }

  std::vector<std::thread> threads;
  for (int t = 0; t < number_of_threads; ++t) {
    threads.push_back(std::thread([&]() {
      std::default_random_engine generator;
      generator.seed(std::chrono::system_clock::now().time_since_epoch().count());
      std::uniform_int_distribution<int> distribution(0, 9);
      for (int i = 0; i < number_of_runs_per_thread; ++i) {
        // add some random delay
        const int wait_time = distribution(generator);

        std::this_thread::sleep_for (std::chrono::milliseconds(wait_time));
        counter++;
      }
    }));
  }

  for (auto &thread : threads) {
    thread.join();
  }

  std::cout << "value of counter is: " << counter << std::endl;
  std::cout << "correct valuee is  : " << number_of_runs_per_thread * number_of_threads << std::endl;

  return 0;
}

 

kompiler og kjør ti ganger med si:

 

$ g++ -O2 threadtest.cpp -lpthread -o threadtest; for i in $(seq 1 10); do echo "RUN $i"; ./threadtest; done
da kan man få noe ala følgende output:

 

 

 

RUN 1
value of counter is: 62
correct valuee is  : 64
RUN 2
value of counter is: 61
correct valuee is  : 64
RUN 3
value of counter is: 62
correct valuee is  : 64
RUN 4
value of counter is: 64
correct valuee is  : 64
RUN 5
value of counter is: 64
correct valuee is  : 64
RUN 6
value of counter is: 64
correct valuee is  : 64
RUN 7
value of counter is: 64
correct valuee is  : 64
RUN 8
value of counter is: 63
correct valuee is  : 64
RUN 9
value of counter is: 63
correct valuee is  : 64
RUN 10
value of counter is: 64
correct valuee is  : 64

 

Altså var det ikke en stor feil hver gang, og den klarer det stort sett riktig, men likevel forekommer det av og til feil. Nå tenk deg at denne race conditionen skjer én gang under oppsett. Det trenger ikke å skje ofte, men det kan skje av og til.

 

Race condition trenger ikke å være eneste grunn til at dette skjer, men det er en av mange mulige opphav til en slik bug. En helt annen kan være at oppsettet kun trigger hvis valg X er satt et annet sted i systemet, selv om valg X ikke kan regnes som feil eller noe som egentlig skal aktivere denne oppførselen.

 

Da gjenstår det jo bare for deg å komme med noe i denne tråden som ikke bare er teoretisk, men et faktum i forhold til skiftende tastaturoppsett, der race conditions er avgjørende for DirectInput.

Endret av Slettet-t8fn5F
Lenke til kommentar
Videoannonse
Annonse
Gjest Slettet-t8fn5F

Det heter jo usannsynlig for en grunn. Og hvertfall for min del var det eneste jeg reagerte på at du sa "Da vil den race condition gjelde alle med samme koden", som er beviselig feil bare ved det faktum at bugs eksisterer. Om det du sier der stemmer betyr det at utviklere aldri har kjørt den koden en bruker har funnet feil ved. Det som nok er nærmere sannheten er at utviklerene aldri har kjørt samme kode under samme omstendigheter. Og der kommmer jo usannsynlightene inn i bildet.

Ja den setningen feil, men så får dere komme med sannsynligheter som er knyttet til hvorfor tastaturoppsettet skifter og knytter det opp mot race conditions.

 

For øvrig ligger det ikke i kjernen av OS'et, men i DirectInput som er en del av directx.

Lenke til kommentar
Gjest Slettet+5132

Da gjenstår det jo bare for deg å komme med noe i denne tråden som ikke bare er teoretisk, men et faktum i forhold til skiftende tastaturoppsett, der race conditions er avgjørende for DirectInput.

Det var da veldig. Jeg har ikke tilgang til kildekoden til Microsoft, så det kan jeg ikke. Du har derimot blitt motbevist så mange ganger i denne tråden at du burde snart unnskylde deg for å spre feilinformasjon.

 

Og du misforstår, enten med vilje eller hva vet vel jeg, når du tror vi sier at race condition er eneste mulige årsak. Det er en av mange mulige forklaringer på at det ikke skjer på ditt system.

Endret av Slettet+5132
Lenke til kommentar
Gjest Slettet+5132

For øvrig ligger det ikke i kjernen av OS'et, men i DirectInput som er en del av directx.

Så nå ror du deg bort ved å si at DirectX ikke er en del av Windows, og dermed er det ikke en bug i Windows?

 

 

 

 

 

Lenke til kommentar
Gjest Slettet-t8fn5F

Så nå ror du deg bort ved å si at DirectX ikke er en del av Windows, og dermed er det ikke en bug i Windows?

 

 

 

 

 

Hvor har jeg sagt at det ikke er en del av Windows?

Lenke til kommentar
Gjest Slettet-t8fn5F

Det var da veldig. Jeg har ikke tilgang til kildekoden til Microsoft, så det kan jeg ikke. Du har derimot blitt motbevist så mange ganger i denne tråden at du burde snart unnskylde deg for å spre feilinformasjon.

 

Og du misforstår, enten med vilje eller hva vet vel jeg, når du tror vi sier at race condition er eneste mulige årsak. Det er en av mange mulige forklaringer på at det ikke skjer på ditt system.

Du har ikke bevist en dritt. Ikke har du kommet med noen forslag heller hva det kan være annet enn en teoretisk mulighet om race conditions. Som om det skulle være svaret på alt som ikke virker.

Endret av Slettet-t8fn5F
Lenke til kommentar
Gjest Slettet+5132

Du har ikke bevist en dritt.

Så du holder fast på påstanden: "Ja om det er feil med Windows, så skal dette oppdages lett og det skal skje med alle som har installert Windows."

 

eller

 

"Da vil den race condition gjelde alle med samme koden."

 

?

Lenke til kommentar
Gjest Slettet-t8fn5F

Så du holder fast på påstanden: "Ja om det er feil med Windows, så skal dette oppdages lett og det skal skje med alle som har installert Windows."

 

eller

 

"Da vil den race condition gjelde alle med samme koden."

 

?

Er det en enten eller, når det er to vidt forskjellige ting du prøver å sammenligne.

Lenke til kommentar
Gjest Slettet-t8fn5F

Så nå ror du deg bort ved å si at DirectX ikke er en del av Windows, og dermed er det ikke en bug i Windows?

 

 

 

 

 

Enda en gang. Hvor har jeg påstått det?

 

Er denne setningen for vanskelig for deg å forstå?

 

 

For øvrig ligger det ikke i kjernen av OS'et, men i DirectInput som er en del av directx.

Om du ikke forstår den, så spør hell om hjelp, så skal jeg forklare den for deg, men slutt å gi meg meninger jeg ikke har fremsatt.

Endret av Slettet-t8fn5F
Lenke til kommentar
Gjest Slettet+5132

Er det en enten eller, når det er to vidt forskjellige ting du prøver å sammenligne.

Står du ved noen av de påstandene fortsatt? Eller forsåvidt står du fortsatt ved "

Så vi er på atomnivå nå... Ja ja hva enn som kreves for at usannsynlige tilfeller skal inntreffe"? Altså i betydning at race condition er på atomnivå.

Lenke til kommentar
Gjest Slettet-t8fn5F

Står du ved noen av de påstandene fortsatt? Eller forsåvidt står du fortsatt ved "

Så vi er på atomnivå nå... Ja ja hva enn som kreves for at usannsynlige tilfeller skal inntreffe"? Altså i betydning at race condition er på atomnivå.

Jeg kan gått stå for den påstanden om at alle som bruker samme versjon av Windows har den samme versjonen av Windows og dermed skulle ha de samme problemene som er forårsaket av Windows, men om noen drivere lager problemer, så rammer det problemet bare de som bruker den versjonen av den driveren.

 

Men enda en gang. Hvor har jeg påstått at DirectX ikke er en del av Windows?

Lenke til kommentar
Gjest Slettet+5132

Jeg kan gått stå for den påstanden om at alle som bruker samme versjon av Windows har den samme versjonen av Windows og dermed skulle ha de samme problemene som er forårsaket av Windows, men om noen drivere lager problemer, så rammer det problemet bare de som bruker den versjonen av den driveren.

Det var ikke spørsmålet. Står du for noen av påstandene jeg viste til?

 

 

Men enda en gang. Hvor har jeg påstått at DirectX ikke er en del av Windows?

Beklager, jeg misforsto hva du mente. Hvorfor dro du inn DirectX i det hele tatt da?

Endret av Slettet+5132
Lenke til kommentar
Gjest Slettet-t8fn5F

Det var ikke spørsmålet. Står du for noen av påstandene jeg viste til?

 

 

 

Beklager, jeg misforsto hva du mente. Hvorfor dro du inn DirectX i det hele tatt da?

Hvilket API tror du driverne til et tastatur programmeres mot?

 

Dion første setning er allerede besvart, men du må nok lese den først.

Lenke til kommentar
Gjest Slettet+5132

Hvilket API tror du driverne til et tastatur programmeres mot?

Hva har det med innlegget du siterte å gjøre derimot?

 

 

Dion første setning er allerede besvart, men du må nok lese den først.

Nope, det har du ikke.

Lenke til kommentar
Gjest Slettet+5132

Allende tilbake i 1965 ble det lager løsninger mot race conditions.

Men så herregud da. Det er masse løsninger mot det, men det er ikke alltid disse har blitt implementert i koden (som den koden jeg viste over), da har en en race condition med de problemer det medfører.

Lenke til kommentar
Gjest Slettet-t8fn5F

Men så herregud da. Det er masse løsninger mot det, men det er ikke alltid disse har blitt implementert i koden (som den koden jeg viste over), da har en en race condition med de problemer det medfører.

Er man klar over at man har en Race condition, så implementere man selvsagt en løsning mot det. Men det er nå særdels svevende å hevde at tastaturoppsett skiftes som en følge av race conditions. Da kan man jo bruke det svaret på alt som man ikke forstår og man fremstår bare som problemorientert kunnskapsløs tufs uten noen former for forslag til tiltak for å løse problemene.

Lenke til kommentar
Gjest Slettet+5132

Er man klar over at man har en Race condition, så implementere man selvsagt en løsning mot det. 

Ja, og generelt er man klar over en bug, så retter man den selvsagt. MEN DET ER IKKE ALLTID AT MAN SER AT DET ER EN RACE CONDITION ELLER GENERELT EN BUG I KODEN. Hvor vanskelig er det å få inn i hodet?

 

Altså, jeg gidder ikke å diskutere mer med mindre du kan bevise at du har så minimal kodekompetanse at du kan rette opp eksempelkode jeg kom med.

Endret av Slettet+5132
Lenke til kommentar
Gjest Slettet-t8fn5F

Ja, og generelt er man klar over en bug, så retter man den selvsagt. MEN DET ER IKKE ALLTID AT MAN SER AT DET ER EN RACE CONDITION ELLER GENERELT EN BUG I KODEN. Hvor vanskelig er det å få inn i hodet?

 

Altså, jeg gidder ikke å diskutere mer med mindre du kan bevise at du har så minimal kodekompetanse at du kan rette opp eksempelkode jeg kom med.

Sikkert ikke så vanskelig som å forstå at man ikke kan gi svevende teoretisk muligheter skylden for noe man så tydeligvis ikke kan eller har evner til å forstå.

 

Skal nå la deg få bevise din mentale alder, ved å la deg få siste ordet.

Lenke til kommentar

Det var da svært så høy DK-effekt det var her inne, da. 

Hvis noen syntes race-condition er svevende teoretisk, kan jeg berolige med at det er førsteårspensum på IT-utdanningen. Likevel har det aldri eksistert så mye race-condition feil i verden som etter at rammeverk basert på Javascript ble det store hotte. Å forvente lineær oppførsel av kode som ved første øyekast er det, men likevel ikke er det, er ikke uvanlig. 

 

Men jeg ville gjettet på at det er noe annet som er galt her. Feil i innstillinger, innstillinger som blir overskrevet av oppdateringer eller installasjoner, eller innstillinger som blir ignorert på grunn av at utvikleren gjorde en assumption. Disse feilene, spesielt den siste, trenger ikke oppleves hos mange fordi det kan være en unnvikende innstilling. For eksempel at US tastaturlayout ikke er installert selv om man bruker US visningsspråk. 

 

- Microsoft driver på med overskriving av innstillinger i hver store halvårlige oppdatering, det vet vi i fra før. Den siste store var altså nå nylig. Det kan føre til en mismatch mellom innstillinger man har satt, innstillinger man får, og noen ganger er disse innstillingene lagret på flere plasser og da blir det mismatch mellom innstillinger man kan se man har og det som faktisk brukes. Kommer et skjermbilde for å demonstrere litt lenger ned straks. 

- Microsoft driver konstant på med å bytte gammel kode med ny og forbedret eller forenklet kode. Da vil det ikke være alt som erstattes 1:1 i funksjonalitet og innstillinger. Disse endringene er ofte ikke avgrenset, slik at ny kode nødvendigvis må samhandle med gammel kode. Da innføres nye bugs. For eksempel så byttet de onscreen keyboard for et par(?) år siden, og det var buggy AF i noen versjoner. Deretter byttet de kode for å rotere skjermen og det var helt krise i noen versjoner. I alle fall har de jobbet med språk o.l. helt siden Windows 8 kom, og ting blir ødelagte og reparerte i prosessen. Bugs finnes - det er så mange forskjellige installasjoner at noen bugs bare rammer et lite antall brukere.

 

Så det skjermbildet jeg nevnte. Merk her mismatch mellom hvilke tastaturoppsett som vises, og hvilke som er tilgjengelige:

post-19503-0-21315600-1561923885_thumb.jpg

Endret av tommyb
  • Liker 2
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...