Przez wiele lat wszyscy, wszyscy łącznie ze specyfikacją, mówili że nie wolno pisać systemów czasu rzeczywistego w Javie. Przyczyną było dość losowe działanie gc, który mógł "przymulić" komputer by wykonać czyszczenie. Tak było do czasu...
system czasu rzeczywistego w javie...
Ciekawe jak to się ma funkcjonalnością/szybkością/stabilnością do np. win98SE/XP/Vista albo jakiegoś linuxa....
Wiesz może jakie to ma wymagania i co oferuje wzamian?
Z tego co pytałem, bo sam się nad tym dość długo zastanawiałem, całość była pokazana na "standardowych" (czyt. Sparc) komputerach sun z systemem solaris. Czyli w praktyce potrzeba Unixa lub linucha z odpowiednią konfiguracją. Na Viscie nie ruszy, bo system jest zbyt powolny. Na XP pewno będzie można zobaczyć już w lutym na spotkaniu Juga jak coś takiego działa.
Nie <ort>patrzałem </ort>w ogole do linka itp. Ale jak można nabudować system czasu rzeczywistego na coś, co tym systemem nie jest o_O
Emocjonalny śmieć napisał(a)
Nie patrzałem w ogole do linka itp. Ale jak można nabudować system czasu rzeczywistego na coś, co tym systemem nie jest o_O
tez mnie wlasnie to maksymalnie zastanawia.. podejrzewam ze pogrzebali w samym solarisie. to sun i to sun, wiec mogli dowoli..
// widzialem kiedyś program w javie odpalany na solarisie na serwerze suna. Program zjadał 8GB ramu i wywalał się z OOM. Jak w koncu poszedł, to przydzielanie studentów do ich grup zajęciowych trwało ~8 godzin - wiec sunowska java na sunie chyba specjalnie lepiej nie działa - bo Boże broń, jeśli ot było to lepiej :D - Q
.. to sobie koziołek zainstalujesz [diabel] [green] [green]
@Emocjonalny śmieć, nie obejrzałeś i mówisz, że się nie da. Powietrza nie a bo go nie widać (chyba, że na śląsku), to się nazywa skrajny empiryzm. Zresztą "nie bycie" w przypadku javy wynikało z trudności technologicznych. Teraz to rozwiązano.
// A gdzie ja napisałem że się nie da? To się nazywa nadinterpretacja. - Q
@quetzalcoatl, dużo zależy od programu i tego jak został napisany. OOM o i ja w C umiem zrobić. Zresztą po wielu latach dogładzania javy pod kątem koncepcji sun wziął się za optymalizację i Java6 działa już zdecydowanie szybciej.
@Deti, głupio wyszło, bo pracuję na kompie suna nad systemem opartym o użyte w przykładzie OSGi. Zresztą tego typu systemów nie stawia się na kompach domowych, zazwyczaj, więc nie ma się co obawiać.
sun wzial sie za optymalizacje i poszerzanie smaczkow skladniowych (@atrybuty, klasy anonimowe itp) bo juz wszyscy mieli dosc i java by padla.. a tak ja to troche odwiezylo na chwile..
Padła by na rzecz czego? Płatnego i słabszego w tedy jeszcze .NETu, mało wydajnego i niebezpiecznego php, czy drogiego w utrzymaniu perla? Na rzecz C/C++, które jako CGI jest mało wydajne czasowo przy tworzeniu aplikacji? Sun od dawna już kieruje się vox populi przy udoskonalaniu javy. Java, a przede wszystkim stojąca za nią koncepcja maszyny wirtualnej to przyszłość, która dodatkowo będzie mocno wspierana przez biznes.
Koziolek: ty jestes dewiantem a ja zgadzam sie z Emocjonalnym - jak mozna robic system czasu rzeczywistego na bazie zwyklego systemu?
Widzialem caly filmik i to co widze to aplikacja dzialajaca na Solarisie - aplikacia != system. To jest jakas sciema ktorej nie kupuje.
poza tym w samym filmiku pojawia sie stwierdzienie "aplication level" - to znaczy ze z systemem to ma nie wiele wspolnego.
Dopisane:
Dodatkowo to co sie dzieje, testy obiciazenia, maja miejce na poziomie aplikacji ktora to obsluguje. A co z systemem ktorym jak wiemy z filmiku jest Solaris i nic nie robi poza tym jednym programem? Pomijajac fakt ze jest to z 2004 roku.
A co za problem dać aplikacje czasu rzeczywistego na system czasu rzeczywistego skoro Java z założenia jest przenośna ? Założe się, że nie długo będzie śmigać chociażby na QNX.
Faszczu napisał(a)
Koziolek: ty jestes dewiantem
Bez wycieczek osobistych, dobrze? :-[
a ja zgadzam sie z Emocjonalnym - jak mozna robic system czasu rzeczywistego na bazie zwyklego systemu?
Można przy spełnieniu pewnych założeń. Np. takich, że zwykły system operacyjny nie zajmuje się równolegle innymi zadaniami o tym samym lub wyższym priorytecie. Tak czy siak, nie ma powodu, by to odpalić na np. RTKernel albo QNX.
Widzialem caly filmik i to co widze to aplikacja dzialajaca na Solarisie - aplikacia != system
http://pl.wikipedia.org/wiki/System
Nie każdy system to aplikacja, ale duże aplikacje zwykle są systemami.
JVM to system runtime.
poza tym w samym filmiku pojawia sie stwierdzienie "aplication level" - to znaczy ze z systemem to ma nie wiele wspolnego.
System czasu rzeczywistego != system operacyjny czasu rzeczywistego.
Poza tym gdzieś tu ktoś napisał, że Vista byłaby zbyt wolna. Argument chybiony. W systemach RT nie chodzi w ogóle o szybkość, tylko o przewidywalny czas odpowiedzi. Wrzucenie Visty na Deep Blue (hehe, gdyby było możliwe) nie zrobi z niej systemu operacyjnego czasu rzeczywistego.
mam takie pytanie: w czym jest napisane JVM ?
Mieszanka C/C++ i asm i od tego są już bardziej zaawansowane funkcjonalności w Javie.
Faszczu napisał(a)
a ja zgadzam sie z Emocjonalnym - jak mozna robic system czasu rzeczywistego na bazie zwyklego systemu?
to i ja się dopiszę :) skoro java działa pod VM, a VM może działać pod systemem nie będącym RTOS'em, bo nie widzę możliwości, żeby program javowy działał jako RTS. Jak np. po windowsem zagwarantować, że wątki javove będą się wykonywały w dokładnie skwantowanej ilości czasu?
dlatego wlasnie sie smialem ze w SunOs'ie tez na pewno grzebali.. a do windozy przyjda z jakimis hardcore'owymi driverami wczepiajacymi sie bog wie gdzie:)
Że tak się spytam, po cholere Sun miałby robić RTS pod Winde ? RTS to już bardziej specjalistyczne zastosowanie niż applet na stronke, który ma działać wszędzie.
Jejku, o czym wy gadacie. To jest zabawne... Poza tym jak ktoś to zauważył aplikacja!=system i tego nie kumam, bo z tematu wnioskować można, że chodzi o system czasu rzeczywistego napisany w javie...
Zresztą temat poniżej pasa. Obraża systemy czasy rzeczywistego (PODKREŚLAM SYSTEMY CZASU RZECZYWISTEGO, nie mylić z systemami operacyjnymi czasu rzeczywistego bo to ogromna różnica). Podkreślenie jest w tym przypadku bardzo ważne, bo nie należy tego mylić. Widzieliście kiedyś prawdziwy system czasu rzeczywistego? Wydaja mi się, że nie. Systemy czasu rzeczywistego wykonywane są w różny sposób i nie zawsze zawierają system operacyjny! Wynika to z wymogów stawianych tym systemom, czasami wymogi czasowe są tak wielkie że czas przerzucania kontekstu trwa dłużej niż 100 kolejnych wywołań przerwań. Poniżej macie kilka linków, gdzie procesor sterujący wraz z elekroniką tworzy system czasu rzeczywistego:
http://www.elektroda.pl/rtvforum/viewtopic.php?t=910623
Wyobraźcie sobie jakie wymagania miałyby te urządzenia, gdyby zastosować w nich elektronikę z prockiem opartym o system operacyjny. Ostatnia gierka jest the best, sporo pracy, najwyższy system czasu rzeczywistego, mimo że prosty, ale wciśnięcie operacji obliczeniowych między synchronizację z obrazem to dosłownie...
Tak więc systemy czasu rzeczywistego to nie aplikacje, to nie systemy operacyjne czasu rzeczywistego. Aplikacje i systemy operacyjne mogą conajwyżej wchodzić w skład systemu czasu rzeczywistego, natomiast same jego nie tworzą. I co najważniejsze te drugie można jeszcze podzielić na miękkie i twarde. Dodatkowo! i to bardzo ważne! Java się po prostu nie nadaje do systemu czasu rzeczywistego. Nawet jak ktoś powie, że coś takiego się da, to dla większości ludzi z tego świata (świata systemów czasu rzeczywistego) będzie to kpina i dobry żart ("dobry żart, tymfa wart"). Systemów czasu rzeczywistego nie tworzy sie po to, by oprogramowanie na nich było pisane w językach bardzo wysokiego poziomu, bo jedno drugiemu przeczy. Języki wysokiego poziomu mogą sterować (wywierać wpływ) na system czasu rzeczywistego, np. w podanym zegarku mogą sterować tym co się wyświetla, ale nie jak się wyświetla. W przypadku gierki pojawiają się jeszcze inne sprawy. Pasmo TV to 6.5MHz. Przeliczcie ile taktów ma proc 1GHz a nawet 3GHz by się tym pasmem stosownie zająć. A na powyższym projekcie zastosowano proc z zegarkiem 16MHz! Co prawda pasmo nieco zostało zmniejszone, co jednak i tak robi ogromne za względu na stosunek zegar/pasmo.
Wywalcie ten temat, bo wiedza tutaj zawarta może wielu ludziom namieszać w głowie, a ludziom zorientowanym, którzy to przeczytają otworzą się noże w kieszeni.
Jakiś czas temu był podobny temat i porozumieniem w tamtym temacie było rozgraniczenie systemu sterowania od elementów wykonawczych. Java do tego pierwszego, reszta (c/c++/asm) do drugiego. W drugim miejscu leżą właśnie systemy czasu rzeczywistego.
RR - mówisz o małych systemikach. Tylko co z większymi (takimi jak np. samolot)? Poszczególne części wykonawcze są bezsystemowe, ale coś tymi częściami musi sterować i zazwyczaj robi to jakiś RTOS.
RR - mówisz o małych systemikach. Tylko co z większymi (takimi jak np. samolot)?
Już pisałem. Małe to SYSTEMY rzeczywiste, a całością steruje komputer(y) z systemem operacyjnym czasu rzeczywistego. Był podobny wątek. Wielkie konstrukcje składają się (tak jak w programowaniu) z obiektów, które dają jakieś interfejsy. Te obiekty zazwyczaj są pełnymi systemami czasu rzeczywistego, bo np. sterują PWMem w czasie rzeczywistym, a współczynnik wypełnienia jest dobierany np. w zależności od obciążenia mechanicznego jakiegoś elementu, tak by w konsekwencji ten element wyglądał jakby nie działała na niego żadna siła. Do sterowania tymi elementami jak najbardziej nadają się systemy operacyjne czasu rzeczywistego... niestety ale również w tych systemach (jeśli jest) Java znajduje się na samym końcu i nawet jeśli jest coś w niej napisane to jej priorytet jest najniższy.
Tak to już wygląda, że w normalnych projektach nawet wielkich prawdziwe systemy czasu rzeczywistego to właśnie elementy te ostatnie, często bezsystemowe. Natomiast do ich sterowania są systemy czasu rzeczywistego z systemem operacyjnym czasu rzeczywistego (miękkim lub twardym). Ale w tych drugich java nadal nie pasi...
Jak już raz wspomniałem... wejdźcie na elektrodę i powiedzcie, że chcecie np. matrycą LCDka sterować. I napiszcie, że chcecie zrobić to na procku z systemem operacyjnym (dowolnym, nawet czasu rzeczywistego) a kod w javie. Jak wam ktoś odpisze to albo to będzie z ciekawości, albo żeby się pośmiać. Podobnie będzie jak zapytacie o obsługę silników krokowych i wiele wiele innych rzeczy. Zapytajcie gdzie takie coś by się nadawało? Okaże się, że nikt nie znajdzie zastosowania dla takiego projektu innego niż sterowanie jakimś układem wykonawczym. Taka jest niestety prawda :).
Poszczególne części wykonawcze są bezsystemowe ale coś tymi częściami musi sterować i zazwyczaj robi to jakiś RTOS.
No właśnie. To co napisałem to dokładnie to, ale java to nadal ostateczność do sterowania tym systemem czasu rzeczywistego, czyli kolejny klocek w hierarchii
@rr, w określeniu "system czasu rzeczywistego" nie jest nigdzie powiedziane, że czasy reakcji mają być nano/mikrosekundowe. Masz rację, do tego mikrosekundowego typu systemów są lepsze rzeczy niż Java czy C (!). Często takiego systemu nawet nie ma co budować na prockach klasy Pentium, Core 2 Duo czy Athlon bo już na poziomie procesora nie da się określić ile czasu co się wykona. Ale to jest tylko FRAGMENT tej dziedziny.
Mówisz, że nikt z nas pwnie nie spotkał się z systemem czasu rzeczywistego? A ja Ci podam przykład: sterowanie światłami ulicznymi. Jak najbardziej system czasu rzeczywistego. Gdyby czerwone raz się swieciło przez 10 sekund, innym razem przez 30 minut, to niezły chaos by zapanował... Innym przykładem są gry komputerowe (soft real time), gdzie liczba FPS nie powinna zmaleć poniżej pewnej wartości. Jeszcze innym streaming audio i video. Do tych ostatnich RT Java nadaje się obecnie nie gorzej niż C++.
Inną dziedziną, niestety na razie chyba tylko akademicką, są bazy danych czasu rzeczywistego. Tam Java też pasuje*.
*) taki offtop: z doświadczenia mogę powiedzieć, że w implementacji silników baz danych Java po prostu wymiata w porównaniu z C czy C++. Oczywiście wszystko się da w nich napisać, ale w Javie robi się to szybciej i przyjemniej, głownie ze względu na GC i dużo lepszy debugger. A jak jest przyjemnie, to i efekty są często lepsze: http://www.h2database.com/html/frame.html?performance.html&main
OT
Krolik napisał(a)
Gdyby czerwone raz się swieciło przez 10 sekund, innym razem przez 30 minut, to niezły chaos by zapanował...
zły przykład bo na coraz większej ilości skrzyżowań tak właśnie jest ;P
RR - nie za bardzo Cię rozumiem. To jest forum programistyczne gdzie w większości użytkownikami są programiści wysokopoziomowi. Nic więc dziwnego, że jak powstaje temat o systemach czasu rzeczywsitego to chodzi o ujęcie wysokopoziomowe.
Mówisz, że nikt z nas pwnie nie spotkał się z systemem czasu rzeczywistego? A ja Ci podam przykład: sterowanie światłami ulicznymi.
zgoda, ale nie dlatego, że tam musi tak być, tylko dla tego, że nikt nie wpadł na genialny pomysł tworzenia kolosa. Zrobili coś z "małym" prockiem i dlatego wyszedł system czasu rzeczywistego. Natomiast w praktyce tak by nie musiało być. Tak się składa, że nawet windows mógłby brać na siebie sterowanie całym miastem (światłami). Przecież to jedynie sekwencja, więc tutaj to raczej logika decyduje o rozwiązaniu (o czym pisałem wcześniej - system czasu rzeczywistego widać też w monitorze, drukarce, telewizorze, zegarku itd. a to dla tego, że tam nie robi się cudów).
w określeniu "system czasu rzeczywistego" nie jest nigdzie powiedziane, że czasy reakcji mają być nano/mikrosekundowe.
Wiem, ale twoje dalsze spostrzeżenie jest także ważne :). Natomiast ja nigdzie tego nie powiedziałem, że tak być musi, ale skoro nie musi to mamy windowsa :). To jeden z najważniejszych czynników. Gdyby nie on to każdy system można byłoby nazwać systemem czasu rzeczywistego, nawet PCty jako całość i windows jako system operacyjny czasu rzeczywistego. Tam liczy się naprawdę wydajność i jak słusznie zauwazyłeś (co zresztą napisałem również i ja wcześniej) większość systemów czasu rzeczywistego oparta jest o procki z oprogramowaniem nie będącym systemem operacyjnym.
RR - nie za bardzo Cię rozumiem. To jest forum programistyczne gdzie w większości użytkownikami są programiści wysokopoziomowi.
Właśnie. Programiści wysokopoziomowi. I tutaj właśnie jest brak waszej podstawowej wiedzy w zakresie elektroniki (bo nie da się ukryć że systemy czasu rzeczywistego i systemy operacyjne czasu rzeczywistego to w większości przypadków znajdują zastosowanie w elektronice). Prawda jest taka, że programowanie wysokopoziomowe i system czasu rzeczywistego ma się tak, jak windows vista do kompów z prockami 486. Jedno drugiemu w zasadzie przeczy. Nie tworzy się systemu czasu rzeczywistego, po to by dla zabawy oprogramować go w języku bardzo wysokiego poziomu takiego jak Java. Systemy czasu rzeczywistego mają konkretne cele, nie mają być proste w utworzeniu (i zazwyczaj nie są) tylko dobre, przemyślane.
Czasami się mówi, że ktoś zrobił coś sztuka dla sztuki np. kiedy zrobił jakieś urządzenie, które faktycznie działa świetnie, ale wszystko pracuje na maksa (np. kod zamiast w C został napisany w ASM, procek dzięki temu można było zwolnić itp). Faktycznie to jest sztuka dla sztuki, ale w takich przypadkach są plusy - koleś nauczył się optymalizacji, bo potrafi zrobić wielkie rzeczy, zmniejszone zostały koszty itp. Natomiast kiedy ktoś tworzy to samo przy pomocy całego system czasu rzeczywistego instalując tam np. linuksa i pisząc wszystko w javie (hipotetycznie), to jest dopiero sztuka dla sztuki, przerost formy nad treścią. Czemu to ma służyć? Żeby pokazać że się da? I co z tego że się da, jak to jedynie ciekawostka, koszt duży itd. Póki co na tym świecie liczy się tworzenie małych rzeczy, bo każdy głupi wie, że autko dobre można zrobić z silnikiem 8 litrów. Ale nie taki jest cel. Liczy się by osiągnąć maksymalne wyniki z możliwie małym silnikiem. To jest dość charakterystyczna cecha systemów czasu rzeczywistego.
Nic więc dziwnego, że jak powstaje temat o systemach czasu rzeczywsitego to chodzi o ujęcie wysokopoziomowe.
Ja też nie widzę w tym nic dziwnego. Niewiedza po prostu wymaga douczenia się :). A prawda jest taka, że jak wcześniej wspomniałem system czasu rzeczywistego i programowanie wysokopoziomowe to żart :). Nie po to się tworzy coś co ma być w zasadzie na maksa zoptymalizowane, by ta optymalizacja była w czymś takim jak Java. Zresztą pomyśl logicznie.
Jak powiedziałem, popytajcie elektroników, to inny świat. Z perspektywy programistów wysokopoziomowych wydaje się, że to dobry tok myślenia, ale tak nie jest. Stajecie przed głupim problemem i okazuje się, że łatwiej jest napisać rozwiązanie w ASM niż w Javie :), bo elektronicy dali takie ograniczenia projektując system, że szok. Może się nawet okazać, że mimo ASMa nadal będziecie musieli optymalizować :P. Tak, tak... to jest właśnie taki świat mimo że to XXI wiek. Wierzcie mi lub nie, ale od paru lat siedzę w elektronice. Trochę wiem w tym temacie i odkąd się tym zajmuje spotkałem wiele różnych urzędzeń (przemysłowych, domowych itp) i naprawdę tylko niewielki odsetek (telefony komórkowe, modemy itp) zawierał w ogóle system operacyjny. Reszta jak zawierała procki to z całą pewnością były pozbawione systemu operacyjnego.
Na dowód swoich twierdzeń - proszę, 3 linki jakie udało mi się znaleźć o javie na elektrodzie (java i uP).
http://www.elektroda.pl/rtvforum/viewtopic.php?p=4084055&highlight=#4084055
http://www.elektroda.pl/rtvforum/viewtopic.php?p=3035659&highlight=#3035659
http://www.elektroda.pl/rtvforum/viewtopic.php?p=2038487&highlight=#2038487
http://forum.mikrokontrolery.net/viewtopic.php?p=3112
http://forum.mikrokontrolery.net/viewtopic.php?t=149&highlight=java
Jak widać wszystkie 3 wątki nie zostały zbyt mocno rozwinięte, a pytania zadawały osoby nie bardzo orientujące się w temacie. Mimo, że jest java na AVRka to jak to wspomniał koleś, zazwyczaj procki są mniejsze lub bardziej obciążone...
Na zakończenie tematu, bo wydaje mi się, że to koniec, powiem, że dawniej jak zaczynałem, czytałem artykuł o programowaniu uP i w ogóle o systemach mikroporocesorowych (RAM, ROM, uP, peryferia). Tam pięknie zostało napisane, że do większości urządzeń wystarczają niewielkie procesory o niewielkich możliwościach, a tam gdzie możliwości potrzebne są duże, tam wszystko się maksymalnie optymalizuje. I ja się pod tym podpisuje :).
Koniec wykładu :).
Widzę, że zamieszałem. I dobrze :) Na początek specyfikacja Real-time Specification for Java:
http://jcp.org/aboutJava/communityprocess/mrel/jsr001/index2.html
Teraz pytanie zainspirowane opisem Królika. System, jakikolwiek, składa się co najmniej z dwóch elementów, jak zatem w prosty sposób zintegrować proces produkcji? Język java doskonale nadaje się do takich prac ponieważ dostarcza spójnego środowiska. To co stoi za interfejsem javowym jest i tak w praktyce jakimś półprzewodnikiem na najniższym poziomie sprzętowym.
Ok inna sprawa. Nikt jeszcze nie wspomniał o systemach czasu rzeczywistego, z których korzystamy na co dzień i są one napisane w Javie. Przyjmując podział za wikipedią (hard/firm/soft) warto zwrócić uwagę wielodostępne systemy rozproszone np. systemy bankowe. To czy system jest czasu rzeczywistego nie jest w żaden sposób determinowane szybkością jego działania, ale za pomocą stwierdzenia czy przekroczenie pewnego czasu wykonania będącego wypadkową czynników wewnętrznych i zewnętrznych może spowodować katastrofę, bardzo poważny błąd, duży problem czy też może zostać olane.operacja na koncie jeżeli nie zostanie zaksięgowana w odpowiednim czasie może spowodować bardzo poważny błąd. Czas ten jest stosunkowo krótki (kilka sekund dla giełdy), ale system taki dostanie tylko poziom firm ponieważ przekroczenie terminu nie stanowi zagrożenia dla zdrowi i życia. Z drugiej strony próba wyhamowania tankowca musi zostać zakończona w ściśle określonym czasie, którego przekroczenie stanowi zagrożenie dla życia ludzi. Można zatem powiedzieć, że system sterujący tą operacją jest ścisły (hard). Jednocześnie sama operacja trwa kilka godzin (spróbuj wyhamować łódź używając wioseł trochę czasu to zajmie tu masz większą skalę).
Moim zdaniem kwestia szybkości działania nie wpływa na określenie czy system jest czy nie jest czasu rzeczywistego. Istotnym czynnikiem jest fakt czy przekroczenie czasu wykonania stanowi lub nie jakieś zagrożenie. Wynika stąd też inny wniosek. Sposób implementacji jest zależny od konkretnego przypadku. Jeżeli chcę mieć urządzenie, które będzie działało w ścisłym reżimie czasowym, które dodatkowo ma bardzo krótkie czasy wykonania to po prostu zlutuję kilka scalaków i nie będę pchał softu. Z drugiej strony jeżeli czas wykonania jest długi mogę użyć języka wysokiego poziomu takiego jak java, bo sama operacja jest np. prosta, ale musi być zakończona i program wysoko poziomowy gwarantuje wykonanie jej o czasie, ale też ułatwia stworzenie takiego systemu.
*) taki offtop: z doświadczenia mogę powiedzieć, że w implementacji silników baz danych Java po prostu wymiata w porównaniu z C czy C++
Hehe, jak w C/C++ optymalizacja była słaba to nic dziwnego. Jakoś mnie jednak nikt nie przekona że java szybsza od C. Jak kod w C jest daleko od optymalnego to owszem (przykład sortowanie w C przy pomocy bąbelkowego, w javie quicksort, wynik łatwo przewidzieć, ale czy wynik o świadczy o tym, że java szybsza? Nie, świadczy o tym, że w C nie postarano się?)
PS. a słyszałeś o bazach danych w ASM? Też takie są.
Pozdro.
Koziołek jak doczytałeś PL wikipedię to masz tam napisane:
Kwestie sporne [edytuj]
Niektórzy autorzy negują powyższy podział, uznając za systemy czasu rzeczywistego wyłącznie te o ostrych ograniczeniach czasowych.
Część autorów za systemy czasu rzeczywistego uznaje tylko te, które są weryfikowalne metodami formalnymi lub zawężając jeszcze bardziej: tylko te, które już zostały zweryfikowane pozytywnie. Dlatego w tym ujęciu powszechnie stosowane określenie, że dane zadanie jest wykonywane "w czasie rzeczywistym", jest traktowane jako nadużycie.
Ja należę do tych negujących, bo taka jest prawda. Do hamowania łodzi spokojnie styknąłby windows :). Jeśli reżim czasowy to 1 minuta to chyba tylko beznadziejny kod mógłby się nie wyrobić w tym czasie nawet pod windowsem (mam na myśli reakcję na określone zdarzenie, nie obliczenia wyniku, bo oczywiście tutaj można się nie zmieścić).
A czynniki to tak. Jak wspomniałem, wiele sprzętu domowego to systemy czasu rzeczywistego, nawet zegarki, monitory, karty graficzne, projektory, telewizory (zwykłe, plazmowe), lodówki itd. Ba, nawet telefon ma coś z systemu czasu rzeczywistego (sterownik wyświetlacza z ostrymi reżimami). Jednak tam gdzie trzeba budować duży system, a czas przebiegu danego procesu jest powolny, to kwestią sporną jest tam stosowanie systemu czasu rzeczywistego... Wystarczają czesto przerwania.
RR - wyjrzyj czasem poza elektronike bo strasznie ogranicza Ci horyzonty. Jeżeli nie zauważyłeś w tym temacie nikt nie poruszał kwestii systemów czasu rzeczywistego osadzonych na małych urządzonkach typu serwomechanizm. Może najpierw sprawdź na wikipedii czym jest 'system', a dowiesz się, że jest to bardzo abstrakcyjne pojęcie. Na system czasu rzeczywistego może się składać system operacyjny czasu rzeczywistego oraz wszystkie urządzenia bezsystemow pracujące w czasie rzeczywistym połączone ze sobą i tworzące całość RTS. Cały temat jest o nowej możliwości JVM do tworzenia aplikacji, reagujących w czasie rzeczywistym. A te aplikacje mogą sterować urządzeniami bezsystemowymi. Jak już pisałem nikt w tym temacie nie postuluje , żeby do jakiegoś regulatora wrzucać Javę.
endl, parafrazując:
wyjrzyj czasem poza programowanie bo strasznie ogranicza Ci horyzonty.
Szkoda gadać. Java w systemach czasu rzeczywistego... no cóż, ten wątek zaniżył poziom forum i cofnął je o jakieś 10 pokoleń. Skoro linki, fakty, wikipedia nie potrafią przekonać niedowiarków, że jest tak jak piszę to cóż. Niektórzy właśnie powinni wyjrzeć poza czasopisma ze świata super sprzętów, a szybko by zrozumieli że świat wygląda inaczej i nawet te super sprzęty często obok javy nawet nie leżały.
PS. ja stoję po stronie tych którzy negują podział wg wikipedii i endl nie pisz bzdór, bo jak widać nie jestem jedyny który to neguje (a wręcz odnoszę wrażenie, że po stronie negujących stoją elektronicy, po stronie zgadzających się stoją programiści wysokopoziomowi, ci przerwsi to stosują, ci drudzy się nt wypowiadają), a taka jest niestety prawda, że jak założymy że dopuszczolny czas reakcji na zdarzenie może być przekroczony (system czasu rzeczywistego z miękkim systemem operacyjnym czasu rzeczywistego) to taki z niego system czasu rzeczywistego jak z javy asembler. Pojęcie systemu czasu rzeczywistego przez programistów jest nadużywane. Nie wiedzą co w ogóle mówią, a potem jak usłyszę że java w systemach czasu rzeczywistego to śmiech mnie bierze, bo kiedy stają przed jakąkolwiek praktyką w jakiejkolwiek firmie szybko zaczynają kumać, że java to rarytas w elektronice... niestety, ale większość sterowników opisanych przeze mnie to nie java... jak już kiedyś powiedziałem w javie może być nadzorowanie pracy jakiegoś systemu czasu rzeczywistego, co nie znaczy, że nadzorca wlicza się w ten system... jeśli człowiek nadzoruje przy pomocy klawiaturki systemem czasu rzeczywistego to raczej nie ma pracy na stanowisku "stanowisko: system czasu rzeczywistego" a conajwyżej "nadzorca systemu czasu rzeczywistego". Różnica ogromna, jak między miotłą, a operatorem miotły...
Radzę pograć w elektrę, wtedy różowy świat znika, a horyzonty się poszerzają. Te kolorowe pisma wywierają zły wpły na ludzi. Myślą oni o zaj....stym postępie jaki się dokonał, jak to cudownie, jak super, a tu co? Nawet monitory mamy na razie gorsze od starych kineskopowych, auta samochodowe wg testu z przed paru dni na www.wp.pl nie dorównują autom tej samej firmy (renomowane firmy) z przed 10 lat mimo, że są zachwalane i postępowe... przetrzyjcie oczy, ten postęp jest sztuczny i to nieźle. Ranking niewypałów byłoby trudno sporządzić. Piszę to, bo niektórzy mają kolorowe gazetki w oczach. Niektórzy podniecają się tranzystorami zdolnymi do pracy przy 50GHz (a nawet było coś o tranzystorach 500GHz)... postęp, jak nic, tylko zastosowania nie ma i jeszcze wiele lat nie będzie bo przy takich częstotliwościach długość połączeń jest tak ważna, że szkoda gadać. Ludzi zalewa się śmieciami, wydaje się, że głupi zegarek za 100zł ma w sobie coś cudownego, a tam co? nic, zoptymalizowana seria bramek takich jak 30 lat temu...
szkoda gadać, poddaje się, bo mi się klawiatura nie potrzebnie wytarła :P
pozdro.
Mnie śmiech bierze jak słysze baza danych w asm.
Skoro linki, fakty, wikipedia nie potrafią przekonać niedowiarków, że jest tak jak piszę to cóż
PS. ja stoję po stronie tych którzy negują podział wg wikipedii
Zaprzeczasz sam sobie [rotfl]
taka jest niestety prawda, że jak założymy że dopuszczolny czas reakcji na zdarzenie może być przekroczony (system czasu rzeczywistego z miękkim systemem operacyjnym czasu rzeczywistego) to taki z niego system czasu rzeczywistego jak z javy asembler
Znowóż błąd. RTS w Javie wcale nie musi przekraczać dopuszczalnego czasu przeznaczonego na odpowiedź.
Nie wiedzą co w ogóle mówią, a potem jak usłyszę że java w systemach czasu rzeczywistego to śmiech mnie bierze, bo kiedy stają przed jakąkolwiek praktyką w jakiejkolwiek firmie szybko zaczynają kumać, że java to rarytas w elektronice
Nie wiem czy zauważyłeś ale nie jesteś na forum poświęconym elektronice. Może odwróćmy sytuacje. Zaproponuj jakiejś firmie programistycznej napisanie bazy danych, obsługującej miliony rekordów w asmie to wyjdziesz z takiej firmy szybciej niż przyszedłeś. Niestety - duże systemy informatyczne nie są pisane w asmie jak 'za starych, dobrych czasów'.