Što se tiče blokiranja, rivan je dao opsežan odgovor, ali nisam siguran da instrukcija ,,cmpxchg'' postoji na i8086.
Dalje, ne znam jesam li sada dobro razumeo.
Na ,,malom'' sistemu se nalazi sav ovaj softver. Dequeue se vrši preko interapta (,,hardverskog''), a enqueue vrši ,,glavni program''.
Pojednostavljena skica svih programa.
Mali sistem:
GlavniProgram:
Enqueue(Broj)
čekaj(10s)
idi na GlavniProgram:
Prekid:
A=Dequeue()
Pošalji(A)
Sada je važno pitanje kako se obezbeđuje da GlavniProgram čeka 10s, odnosno kako stižu Enqueue zahtevi? Ukoliko je to neki ciklus na osnovu kalibrisanih vrednosti, onda je ostalo jednostavno.
prvo rešenje...
Kada je red prazan, a inicira se ,,Prekid'', u Dequeue postaviš odgovarajući flag, i izađeš, a ništa ne šalješ. Zatim, u Enqueue, ukoliko je postavljen ovaj flag, njega isključiš, ubaciš vrednost u red, i zatim iniciraš prekid ,,Prekid''.
Ukoliko je pri Enqueue red pun, onda vršiš ,,blokiranje'' jednim ciklusom koji proverava novi flag.
Problem sa ovim pristupom je što je nemoguće ovo što ti pominješ: da se uradi nekoliko ,,Enqueue'' kada je red pun. Međutim, ukoliko nemaš nikakvu drugu memoriju na raspolaganju (a ako imaš, trebalo bi povećati red), onda se ovo pitanje rešava dizajn odlukom: pokušavaš da pošalješ prvi podatak iz reda (nadajući se da računar na suprotnoj strani isto može da čeka dok ne stigne zahtev za tim podatkom) i dodaješ novi podatak, ili prosto zanemaruješ novi podatak.
Sigurno je jasno da je teorijski nemoguće rešiti problem manjka memorije bez memorije :)
i drugo...
Ukoliko se razmak između punjenja Enqueue odvija pomoću tajmera (PIT 8253) ili nekog drugog prekida (u svakom slučaju radi se o prekidu), onda je zgodno koristiti taj prekid za semafore, i ,,scheduler'' (jednostavni naravno).
Tada bi se GlavniProgram pozivao, i ukoliko je jedan ili više GlavniProgram-a već aktivno, onda ga samo ubaciš u red za izvršavanje (ovo nije isti red, već ,,lista procesa'') i zapamtiš odgovarajući parametar (npr. neka kroz AX registar prosleđuješ parametar Enqueue, onda njega pamtiš uz svaki element liste), i kad ima mesta u redu, onda pozoveš iz prekida (tajmer ili šta već) GlavniProgram sa prvim parametrom. Ovo je običan FIFO ili FCFS (First Come-First Served) algoritam.
Prednost ovakvog rešenja je što bi sve radilo kako si zamislila (do memorijske granice), ali mana je što bi morala da razviješ i memory allocation algoritam (first-fit kao najjednostavniji pada na pamet), i sam FIFO/FCFS scheduler.
Isto to, ako ne i bolje rešenje se može obezbediti dinamičkim povećavanjem reda, i njegovim smanjivanjem na ,,uobičajenu'' veličinu: kada je red pun, onda ga proširi za jedno mesto pri Enqueue, a pri Dequeue, ukoliko je duži od inicijalne vrednosti, onda izbaci jednu vrednost, i smanji red za jedno mesto (pa će i dalje biti pun). Ovo je znatno jednostavnije, a obezbeđuje svu funkcionalnost (opet do memorijske granice).
Ukoliko ti nije dozvoljeno da pristupaš većoj količini memorije (npr. nije tvoj softver jedini na sistemu, a nemaš na raspolaganju neki servis za dodelu memorije), onda ti ne preostaje ništa drugo do da zanemariš/odbaciš novopristigle vrednosti za koje nema mesta u redu (jedna vrednost može blokiranjem, ali ne i više od jedne), ili odgovornost prebaciš na primaoca time što ćeš poslati vrednost preko serijske veze i kada nije tražena.
Obični uređaji uglavnom koriste odbacivanje vrednosti (npr. tastatura, setimo se ,,bipa'' koji označava ,,bafer mi je pun''), ali to zavisi od toga šta ti je potrebno. Za realtime sistem, mislim da je povoljnije odbaciti prve vrednosti (pošto će one ionako biti sa velikim kašnjenjem), ali sve već zavisi od konkretne aplikacije.
PS. Elitesecurity radi slabo kada je najveća gužva, a to je upravo vreme u koje si slala poruku. Svakako, možeš se javiti i na email, ali ja mogu dati odgovora na vrlo malo
konkretnih pitanja, pošto i8086 ne poznajem dovoljno. Ipak, bolje je zadržati diskusiju na forumu, pošto onda postoji mogućnost da se neko ko više zna od mene uključi u nju.
Možda se moje mišljenje promenilo, ali ne i činjenica da sam u pravu.
mali multitasking os
Re: mali multitasking os
