Paar vragen over Windows voor school.

[Shiske]

Ik moet voor school een aantal vragen maken over het besturingssysteem windows.
Ik heb er een boek voor maar daar mist nogal wat informatie waardoor ik een aantal vragen ongeveer weet ik en twijfel vaak tussen twee goeie antwoorden. Ik heb al veel op Internet gekeken maar daar ik het telkens net niet vinden dus ik hoopte dat hier iemand het weet of mij op weg kan helpen.
De vragen zijn als volgt:

Vraag 03
We gaan uit van een processor die twee toestanden (modi) kent: user mode en kernel mode. Welke actie(s) MOET(en) in kernel mode worden uitgevoerd?
A) Het uitvoeren van een complexe berekening
Het uitlezen van het toetsenboard
C) Geen van bovenstaande acties
D) Beide bovenstaande acties

Ik vermoed dat dit A maar weet ik niet zeker

Vraag 19
Hoeveel processen en systeemvoorzieningen (resources) zijn er betrokken bij een deadlock situatie?
C) Minimaal 2 processen, mimimaal 1 resource
D) Minimaal 2 processen, minimaal 2 resources

Volgens mij is dit D maar ik weet niet zeker of 2 processen gebruik kunnen maken van 1 dezelfde resource. (deadlock situatie is overigens dat 2 processen op elkaar zitten te wachten en dus eigenlijk tot 1 van de twee iets gaat doen).


Vraag 21
Binnen Windows scripting Host kunnen standaard twee scripttalen gebruikt worden: Jscript en VBscript. Welke scripttaal is het meest geschikt om met COM objecten te werken.
A) Jscript
VBscript
C) Beide kunnen even goed met Com objecten overweg
D) Beide kunnen niet met Com objecten overweg

Hier kon ik dus echt niks zinnigs over vinden, dit staat ook echt nergens in het boek.


Vraag 23
In Batch files wil je vaak dat commando’s geen output op het scherm zetten. Bovendien wil je niet zien welk commando wordt uitgevoerd. Op deze manier kun je je eigen schermoutput regelen. Hoe krijg je dit voor elkaar?
A) Begin de batchfile met het commando @Echo Off
Redirect de output van een commando naar het nuldevice/
C) Gebruik zowel @Echo Off als redirection naar het nulldevice

Hiervan weet ik dat het met @echo off kan, maar ik geloof dat het vroeger ook gedaan werd met redirect van de output van een commando naar het nuldevice maar dat dat niet zo betrouwbaar was.
Dus eigenlijk twijfel ik tussen A of C.


Vraag 31
Welke van de volgende devices zal GEEN gebruik maken van DMA?
A) Netwerkkaart
Geluidskaart
C) Harde schijf
D) Toetsenbord

Ik denk dat het D is maar op Internet kwam ik op pagina's waarvan beweerd werd dat ze allemaal gebruik maakten van DMA,.Maar volgens mij gebruikt toetsenbord interrupted I/O maar ik weet dit niet zeker.

---

Aardig wat tekst dus maar met ieder goed antwoord schiet ik een behoorlijk groot stuk op, ik weet ook niet of het hele moeilijk vragen zijn of zo.

Dit zijn trouwens wat bronnen die ik gebruikt heb
http://www.tweakzone.nl/begrippen/
http://www.gnu.org/softwa...l/html_node/Glossary.html
http://www.cise.ufl.edu/r...llelPatterns/glossary.htm

[Verwijderd]

de bedoeling is dat jezelf je huiswerk maakt en niet post op dit forum

[Wokkel1982]

Verwijderd schreef op zondag 25 september 2005 @ 16:44:
de bedoeling is dat jezelf je huiswerk maakt en niet post op dit forum

Het gaat er om dat hij zijn best erop gedaan heeft (En dat lijkt me hier wel het geval).

[FiXeR.nl]

Verwijderd schreef op zondag 25 september 2005 @ 16:44:
de bedoeling is dat jezelf je huiswerk maakt en niet post op dit forum

De bedoeling is dat het GOED is, niet hoe je het maakt!

[Mad Marty]

FiXeR.nl schreef op zondag 25 september 2005 @ 16:48:
[...]


De bedoeling is dat het GOED is, niet hoe je het maakt!

De bedoeling is dat je het ZELF maakt, en je LEERT van je fouten!

[Iet]

Ja laten we de manier van 'leren' even gaan bediscussieren hier... (En al helemaal die op een ICT opleiding, waar het nogal eens schort aan fatsoenlijk 'onderwijs')

Verwijderd schreef op zondag 25 september 2005 @ 16:44:
de bedoeling is dat jezelf je huiswerk maakt en niet post op dit forum

Tja, iemand helpen is ook zoiets...? Het gaat hier niet om een vraagdump oid.


ps. @TS: Ik kan je niet helpen aangezien ik geen van de vragen echt met 100% durf te zeggen. ..Oh behalve die van het toetsenbord en DMA? (die niet dus )

[ Voor 24% gewijzigd door Iet op 25-09-2005 16:56 ]

[YopY]

Misschien een goed idee voor een subforum: Tweakers.net Huiswerkhulp .

IIG, dit soort vragen moet in het boek staan en/of op internet te vinden zijn. Indien dat niet het geval is, lever een klacht in bij de school dat de leermiddelen onvoldoende zijn, en dat de vraagstukken niet getuned zijn op de leermiddelen.

[SilentStorm]

Shiske schreef op zondag 25 september 2005 @ 16:35:
Vraag 03
We gaan uit van een processor die twee toestanden (modi) kent: user mode en kernel mode. Welke actie(s) MOET(en) in kernel mode worden uitgevoerd?
A) Het uitvoeren van een complexe berekening
Het uitlezen van het toetsenboard
C) Geen van bovenstaande acties
D) Beide bovenstaande acties

Ik vermoed dat dit A maar weet ik niet zeker

Bij kernel mode moet je denken aan low-level hardware calls. Ik denk dat je het antwoord dan wel kan geven

Vraag 19
Hoeveel processen en systeemvoorzieningen (resources) zijn er betrokken bij een deadlock situatie?
C) Minimaal 2 processen, mimimaal 1 resource
D) Minimaal 2 processen, minimaal 2 resources

Volgens mij is dit D maar ik weet niet zeker of 2 processen gebruik kunnen maken van 1 dezelfde resource. (deadlock situatie is overigens dat 2 processen op elkaar zitten te wachten en dus eigenlijk tot 1 van de twee iets gaat doen).

Je zit in de buurt. Het idee is dat twee processen op elkaar wachten, omdat ze allebei met hetzelfde resource bezig zijn. 1 Resource is dus genoeg.
(bv proces 1 vraagt lock aan op resource, maar kan er niets mee doen tot proces2 er iets mee gedaan heeft. Proces2 wacht tevergeefs op het releasen van het lock door proces1).

Vraag 21
Binnen Windows scripting Host kunnen standaard twee scripttalen gebruikt worden: Jscript en VBscript. Welke scripttaal is het meest geschikt om met COM objecten te werken.
A) Jscript
VBscript
C) Beide kunnen even goed met Com objecten overweg
D) Beide kunnen niet met Com objecten overweg

Ik heb helaas met beiden weinig ervaring, maar ik _denk_ dat alleen VBscript hiermee om kan gaan.

Vraag 23
In Batch files wil je vaak dat commando’s geen output op het scherm zetten. Bovendien wil je niet zien welk commando wordt uitgevoerd. Op deze manier kun je je eigen schermoutput regelen. Hoe krijg je dit voor elkaar?
A) Begin de batchfile met het commando @Echo Off
Redirect de output van een commando naar het nuldevice/
C) Gebruik zowel @Echo Off als redirection naar het nulldevice

Hiervan weet ik dat het met @echo off kan, maar ik geloof dat het vroeger ook gedaan werd met redirect van de output van een commando naar het nuldevice maar dat dat niet zo betrouwbaar was.
Dus eigenlijk twijfel ik tussen A of C.

met @echo off (of eigenlijk elke regel waar je echo voor zet), geef je aan dat je het door jou uitgevoerde commando niet op het scherm wil hebben (daarom staat er ook een @ voor echo off zelf). Met de output naar het null device, zorg je ervoor dat de output van het commando ook niet zichtbaar is voor de gebruiker.
(bv '@dir' geeft je een directory listing zonder dat 'dir' erboven staat. 'dir > null' geeft je alleen 'dir' erboven. Je had het natuurlijk zelf ook even kunnen proberen in een command shell

Vraag 31
Welke van de volgende devices zal GEEN gebruik maken van DMA?
A) Netwerkkaart
Geluidskaart
C) Harde schijf
D) Toetsenbord

Ik denk dat het D is maar op Internet kwam ik op pagina's waarvan beweerd werd dat ze allemaal gebruik maakten van DMA,.Maar volgens mij gebruikt toetsenbord interrupted I/O maar ik weet dit niet zeker.

DMA staat voor direct memory access. Je zou zelf voor de aardigheid eens kunnen kijken in de device manager welke devices wel en niet DMA gebruiken. Misschien kun je, als je het antwoord gevonden hebt, ook navertellen waarom dat het geval is?

Verwijderd schreef op zondag 25 september 2005 @ 16:44:
de bedoeling is dat jezelf je huiswerk maakt en niet post op dit forum

Ik denk dat het een beter idee is om die beslissing over te laten aan de mods. De TS heeft niet gewoon een stel vragen gedumpt, maar actief naar oplossingen gezocht en de overgebleven vragen met eigen inzichten hier neergezet. Met zo'n instelling ben ik iig niet te beroert om er ook even wat tijd in te steken.

Ik stel voor dat we een verdere discussie over het wel of niet toestaan van huiswerk even laten liggen en verder gaan met de inhoud? (zie daarover nog Huiswerktopics zijn niet per definitie fout! (pw), Algemene gedragsregels (Netiquette), en [search=huiswerk]

[Plopeye]

Shiske schreef op zondag 25 september 2005 @ 16:35:


Vraag 23
In Batch files wil je vaak dat commando’s geen output op het scherm zetten. Bovendien wil je niet zien welk commando wordt uitgevoerd. Op deze manier kun je je eigen schermoutput regelen. Hoe krijg je dit voor elkaar?
A) Begin de batchfile met het commando @Echo Off
Redirect de output van een commando naar het nuldevice/
C) Gebruik zowel @Echo Off als redirection naar het nulldevice

Hiervan weet ik dat het met @echo off kan, maar ik geloof dat het vroeger ook gedaan werd met redirect van de output van een commando naar het nuldevice maar dat dat niet zo betrouwbaar was.
Dus eigenlijk twijfel ik tussen A of C.


Vraag 31
Welke van de volgende devices zal GEEN gebruik maken van DMA?
A) Netwerkkaart
Geluidskaart
C) Harde schijf
D) Toetsenbord

Ik denk dat het D is maar op Internet kwam ik op pagina's waarvan beweerd werd dat ze allemaal gebruik maakten van DMA,.Maar volgens mij gebruikt toetsenbord interrupted I/O maar ik weet dit niet zeker.

Wat betreft vraag 23: zou ik zeggen antwoord D.
@echo off zorgt ervoor dat het uitgevoerde commando net zichtbaar is...
redirection naar nulldevice zorgt ervoor dat het uitvoer van het commando cq aangeroepen programma
niet zichtbaar word...

wat betreft vraag 31:

Volgens mij gebruikt een toetsenbord geen DMA. een geluidskaart zeker weten wel... dit was vroeger onder dos al op te maken uit de volgende regel uit de autoexec.bat file als je een soundblaster of compatible had...
SET BLASTER=A220 I5 D1 T3 P330 H6 E620
waar de uitleg is als volgt:
A220 = Port adress
I5 = IRQ 5
D1 = DMA channel 1
de rest laat ik maar achterwege omdat dit niet relevant is...

[Verwijderd]

je kunt hem best helpen maar niet door te zeggen a is het je kunt hem beter een tekst geven dat die het zelf uit kan zoeken zo leer je niks

[Verwijderd]

Shiske schreef op zondag 25 september 2005 @ 16:35:
Vraag 03
We gaan uit van een processor die twee toestanden (modi) kent: user mode en kernel mode.

De vraag is incorrect. Een CPU kent geen user of kernel mode, althans, de huidige CPU's nog niet.

Welke actie(s) MOET(en) in kernel mode worden uitgevoerd?

Geen van alle moet persé in de kernel gebeuren. Dat is aan de ontwikkelaar om te kiezen.

Vraag 19
Hoeveel processen en systeemvoorzieningen (resources) zijn er betrokken bij een deadlock situatie?
C) Minimaal 2 processen, mimimaal 1 resource
D) Minimaal 2 processen, minimaal 2 resources

Wederom een foute vraag, of althans, foute antwoorden. Een deadlock kan al optreden met 1 proces en geen resource.

Vraag 23
C) Gebruik zowel @Echo Off als redirection naar het nulldevice

@echo off voorkomt dat het commando wordt weergegeven, maar doet niets met de output. De volgende batchfile bv:

code:

@echo off
dir c:\

Zal als output de directory-listing van c: hebben. Je moet dus ook de output redirecten.

Je vragen zijn een schoolvoorbeeld van waarom ik 'computeronderwijs' in NL slecht vind. De vragen kloppen al niet eens.

[Reptile209]

SilentStorm schreef op zondag 25 september 2005 @ 17:07:
[...]

Je zit in de buurt. Het idee is dat twee processen op elkaar wachten, omdat ze allebei met hetzelfde resource bezig zijn. 1 Resource is dus genoeg.
(bv proces 1 vraagt lock aan op resource, maar kan er niets mee doen tot proces2 er iets mee gedaan heeft. Proces2 wacht tevergeefs op het releasen van het lock door proces1).

Als proces 1 een lock op resource 1 heeft, kan hij daar zijn ding mee doen en 'm vrijgeven. 2 wacht daar netjes op. Een deadlock ontstaat als proces 1 resource 1 lockt en een lock aanvraagt op resource 2. Die krijgt hij in dit geval niet, omdat proces 2 resource 2 al gelockt heeft en wacht op een lock op resource 1. In dit geval wachten beiden oneindig lang op elkaar -> deadlock.
Zie ook http://en.wikipedia.org/wiki/Deadlock

Verwijderd schreef op zondag 25 september 2005 @ 17:20:
[...]

Wederom een foute vraag, of althans, foute antwoorden. Een deadlock kan al optreden met 1 proces en geen resource.

Hoe wil je een deadlock hebben met één proces en geen resource? Bedoel je niet een ordinaire vastloper omdat iemand een eindeloze lus programmeert ofzo? Of gaat je proces zitten wachten op het verkrijgen van een resource die niet bestaat?

[ Voor 30% gewijzigd door Reptile209 op 25-09-2005 17:33 ]

[Verwijderd]

Reptile209 schreef op zondag 25 september 2005 @ 17:29:
Hoe wil je een deadlock hebben met één proces en geen resource? Bedoel je niet een ordinaire vastloper omdat iemand een eindeloze lus programmeert ofzo? Of gaat je proces zitten wachten op het verkrijgen van een resource die niet bestaat?

Het hangt van je definitie van deadlock af. Een deadlock is domweg niets anders dan wachten op iets wat niet zal gebeuren door een fout in je flow.

code:

stop=true
repeat
  code
until stop=false
stop=false

Dit is al een deadlock.

[Haan]

Verwijderd schreef op zondag 25 september 2005 @ 17:38:
[...]


Het hangt van je definitie van deadlock af. Een deadlock is domweg niets anders dan wachten op iets wat niet zal gebeuren door een fout in je flow.

code:

stop=true
repeat
  code
until stop=false
stop=false

Dit is al een deadlock.

Deadlock zoals de TS het bedoelt is dat 2 processen allebei wachten op een actie van de ander voordat ze door kunnen. Dus niet zoals in jouw voorbeeld.
En zoals hierboven al gezegd, heb je daar 2 resources voor nodig om te kunnen gebeuren.

[ Voor 8% gewijzigd door Haan op 25-09-2005 17:46 ]

[mbaltus]

Een deadlock heeft slechts 1 resource nodig. Bijvoorbeeld in DB benadering (?bij optimistic locking?):
1. proces1 wil uit een tabel iets lezen en vraagt daarvoor een read-lock aan, die door het DBMS toegekend wordt.
2. proces 2 wil uit dezelfde tabel iets lezen en vraagt daarvoor ook een read-lock aan, die door het DBMS toegekend wordt, want twee read-locks is geen gevaar!
3. proces1 wil vervolgens een aanpassing doen, en vraagt daarvoor een write-lock aan. Dit zal moeten wachten, omdat proces2 nog een read-lock heeft.
4. proces2 wil ook wat schrijven en vraagt ook een write-lock aan, en zal ook moeten wachten tot de read-lock van proces1 is opgeheven (en de update actie van proces1 is afgelopen).

Hoewel dit misschien slecht ontwikkelde programmatuur lijkt, is het op deze manier dus wel mogelijk met twee processen en één resource.

[Verwijderd]

Haan schreef op zondag 25 september 2005 @ 17:41:
Deadlock zoals de TS het bedoelt is dat 2 processen allebei wachten op een actie van de ander voordat ze door kunnen. Dus niet zoals in jouw voorbeeld.
En zoals hierboven al gezegd, heb je daar 2 resources voor nodig om te kunnen gebeuren.

Je verwart resources met processen en daarnaast heb je domweg geen gelijk.

Wat men in de vraagstelling wil horen als antwoord, is dat voor een deadlock 2 processen en 1 resource nodig zijn. Ik ben het daar niet mee eens, maar dat is het antwoord wat men wil horen.

Proces 1 locked de resource en daardoor kan proces 2 er niet bij.

[ Voor 4% gewijzigd door Verwijderd op 26-09-2005 11:30 ]

[Haan]

Verwijderd schreef op maandag 26 september 2005 @ 11:30:
[...]


Je verwart resources met processen en daarnaast heb je domweg geen gelijk.

Wat men in de vraagstelling wil horen als antwoord, is dat voor een deadlock 2 processen en 1 resource nodig zijn. Ik ben het daar niet mee eens, maar dat is het antwoord wat men wil horen.

Proces 1 locked de resource en daardoor kan proces 2 er niet bij.

En dan? Proces 2 wacht tot proces 1 klaar is en ze gaan allebei vrolijk verder.

Het zou dan natuurlijk kunnen dat het eerste proces in een oneindige loop hangt, maar dat is niet het idee van een deadlock waar 2 processen wachten op een actie van de ander voor ze verder kunnen.

(ik zal vanmiddag nog eens een boek opzoeken en kijken of het daar wat duidelijker staat dan ik zelf kan verwoorden )

[ Voor 8% gewijzigd door Haan op 26-09-2005 11:43 ]

[RayNbow]

Verwijderd schreef op zondag 25 september 2005 @ 17:20:
[...]


De vraag is incorrect. Een CPU kent geen user of kernel mode, althans, de huidige CPU's nog niet.

Motorola 68k: http://www.codeguru.com/C...opment/article.php/c8035/

Verwijderd schreef op zondag 25 september 2005 @ 17:38:
[...]


Het hangt van je definitie van deadlock af. Een deadlock is domweg niets anders dan wachten op iets wat niet zal gebeuren door een fout in je flow.

code:

stop=true
repeat
  code
until stop=false
stop=false

Dit is al een deadlock.

Dat is geen deadlock, dat is gewoon een oneindige lus..

[ Voor 10% gewijzigd door RayNbow op 26-09-2005 11:47 ]

[RobLemmens]

Verwijderd schreef op zondag 25 september 2005 @ 17:20:
[...]

De vraag is incorrect. Een CPU kent geen user of kernel mode, althans, de huidige CPU's nog niet.

Heb nieuws voor je, huidige intel processors hebben vier executie ringen, 2 meer dan dat er gebruikt worden... Deze bevatten zelfs instructies om snel te wisselen tussen de twee. Het eerste windows OS die dit gebruikte was volgens mij XP.

[PenguinPower]

Vraag 21
Binnen Windows scripting Host kunnen standaard twee scripttalen gebruikt worden: Jscript en VBscript. Welke scripttaal is het meest geschikt om met COM objecten te werken.
A) Jscript
B} VBscript
C) Beide kunnen even goed met Com objecten overweg
D) Beide kunnen niet met Com objecten overweg

Hier kon ik dus echt niks zinnigs over vinden, dit staat ook echt nergens in het boek.

Beetje een rotvraag.
Zowel Jscript als VBscript kunnen alleen voor wsh gelicenceerde activeX objecten aanroepen. Over het algemeen heeft JScript meer regels daarvoor nodig, maar de werking is het zelfde.

[Verwijderd]

Geen van alle moet persé in de kernel gebeuren. Dat is aan de ontwikkelaar om te kiezen.

En die ontwikkelaar die zijn vage app in kernel mode laat draaien, is een achterlijke randdebiel. En vervolgens zeuren dat windows zo instabiel is...

[Verwijderd]

RayNbow schreef op maandag 26 september 2005 @ 11:43:
Motorola 68k: http://www.codeguru.com/C...opment/article.php/c8035/

Ik neem aan dat het hier over windows gaat. Dan is de motorola dus niet van toepassing.

Dat is geen deadlock, dat is gewoon een oneindige lus..

Het is een deadlock, ontstaan door een oneindige lus.

[Verwijderd]

RobLemmens schreef op maandag 26 september 2005 @ 11:51:
Heb nieuws voor je, huidige intel processors hebben vier executie ringen, 2 meer dan dat er gebruikt worden... Deze bevatten zelfs instructies om snel te wisselen tussen de twee. Het eerste windows OS die dit gebruikte was volgens mij XP.

vziw betaat er geen 'kernel mode' of 'user mode' voor intel CPU's. Ik weet wel dat dit er wel zit aan te komen.

Ringen hebben daar voor de rest weinig mee te maken. Het gaat er om wat het OS daar mee doet. Daarmee is het dus een OS-specifiek iets, en niet een CPU specifiek iets, zoals in de vraag wordt gesteld.

Verwijderd schreef op maandag 26 september 2005 @ 12:27:
En die ontwikkelaar die zijn vage app in kernel mode laat draaien, is een achterlijke randdebiel. En vervolgens zeuren dat windows zo instabiel is...

Zonder meer, daar heb je helemaal gelijk in, echter de vraag stelt dat het moet, hetgeen niet waar is.

Haan schreef op maandag 26 september 2005 @ 11:40:
En dan? Proces 2 wacht tot proces 1 klaar is en ze gaan allebei vrolijk verder.

Het zou dan natuurlijk kunnen dat het eerste proces in een oneindige loop hangt, maar dat is niet het idee van een deadlock waar 2 processen wachten op een actie van de ander voor ze verder kunnen.

(ik zal vanmiddag nog eens een boek opzoeken en kijken of het daar wat duidelijker staat dan ik zelf kan verwoorden )

Je hebt gewoon niet gelijk. Kijk naar een database. User a update veld x van waarde 1 naar 2. User b wil datzelfde veld updaten van waarde 1 naar 3. De database werkt met transacties. De transactie van user1 wordt als eerste verwerkt, de transactie van user2 zal als foutmelding een deadlock geven, omdat de uitgangspositie voor die transactie (veld x heeft waarde 1) niet meer bestaat.

Zodra proces1 iets verandert zodanig dat de uitgangspositie van proces2 niet meer klopt, kan er sprake zijn van een deadlock, zonder dat er een oneindige loop is.

[ Voor 59% gewijzigd door Verwijderd op 26-09-2005 14:49 ]

[FragDaddy]

Verwijderd schreef op maandag 26 september 2005 @ 12:27:
[...]

En die ontwikkelaar die zijn vage app in kernel mode laat draaien, is een achterlijke randdebiel. En vervolgens zeuren dat windows zo instabiel is...

Schrijf jij maar eens een applicatie die bijvoorbeeld de communicatie van het OS naar de videokaart in de gaten houdt of een andere vrij diepe systeemfunctie / hardwaredrivers wil controleren/beheren.

[Verwijderd]

Verwijderd schreef op maandag 26 september 2005 @ 14:45:
[...]
vziw betaat er geen 'kernel mode' of 'user mode' voor intel CPU's. Ik weet wel dat dit er wel zit aan te komen.

Intel CPU's hebben oa. priviledged (kernel) en non-priviledged mode (user mode). Wat je zegt is dus onzin.

Verwijderd schreef op maandag 26 september 2005 @ 14:44:
Ik neem aan dat het hier over windows gaat. Dan is de motorola dus niet van toepassing.

Windows NT werkt o.a. ook op Motorola CPU's

Verwijderd schreef op maandag 26 september 2005 @ 14:44:
Het is een deadlock, ontstaan door een oneindige lus.

Zoek eens op wat de definitie van dead-lock is. Dan zal je zien dat een oneindige lus geen deadlock situatie is. ( http://www.google.com/sea...defmore&q=define:Deadlock )

mbaltus schreef op maandag 26 september 2005 @ 10:26:
[... Heel verhaal over databases en locking ...]

Hoewel dit misschien slecht ontwikkelde programmatuur lijkt, is het op deze manier dus wel mogelijk met twee processen en één resource.

Het gaat in je verhaal om twee resources, een read-lock en een write-lock (op hetzelfde object weliswaar, maar we hebben het wel over 2 verschillende zaken)

[RobLemmens]

Verwijderd schreef op maandag 26 september 2005 @ 14:45:
[...]

vziw betaat er geen 'kernel mode' of 'user mode' voor intel CPU's. Ik weet wel dat dit er wel zit aan te komen.

Het heet inderdaad niet kernel of user mode maar de ringen zijn wel datgene wat de hardware matige support leveren voor het onderscheid tussen de twee. Kernel en User mode zijn inderdaad geen eigenschappen van de cpu maar van het os, het principe van verschillende executie layers (kernel/user) daarentegen is wel een eigenschap van de cpu en zit er al heel lang in. Ring 0 is de layer voor Kernel Mode, en Ring 3 voor User Mode. Ring 1 en 2 worden niet gebruikt omdat windows ontworpen is voor meerdere hardware platformen met cpu's die niet allemaal 4 ringen ondersteunen. Tis maar een naampje voor het beestje.

[Verwijderd]

Verwijderd schreef op maandag 26 september 2005 @ 14:56:
Intel CPU's hebben oa. priviledged (kernel) en non-priviledged mode (user mode)

Wat ik zeg is zeker geen onzin. Jij voegt zelf iets tussen haakjes toe wat niet waar is. Privileged heeft niets met kernel-mode te maken. Het kan door het OS als zodanig gebruikt worden, dat maakt het echter nog geen 'kernel-mode'.

Windows NT werkt o.a. ook op Motorola CPU's

Noem mij eens 1 fabrikant die een desktop PC levert met windows NT op een motorola?

Zoek eens op wat de definitie van dead-lock is. Dan zal je zien dat een oneindige lus geen deadlock situatie is. ( http://www.google.com/sea...defmore&q=define:Deadlock )

Kennelijk zijn wij het niet eens over de definitie van een deadlock. Ik denk niet dat het voor TS zinvol is om daar over door te emmeren.

[Verwijderd]

Verwijderd schreef op maandag 26 september 2005 @ 15:17:
Noem mij eens 1 fabrikant die een desktop PC levert met windows NT op een motorola?

Motorola bijvoorbeeld Die leverden desktop PCs met Windows NT.

Verwijderd schreef op maandag 26 september 2005 @ 15:17:
Kennelijk zijn wij het niet eens over de definitie van een deadlock. Ik denk niet dat het voor TS zinvol is om daar over door te emmeren.

Ik geloof dat jij het niet eens bent met de rest van de wereld. Lees voor de grap nu eens die definities door op die google pagina en je zult zien dat een oneindige lus aan geen enkele definitie voldoet.

[_eXistenZ_]

Anyway, het antwoord is 2 processen en 2 resources.
Dit is namelijk Mediatecnologie 1e jaars aan de HU in amersfoort, ik heb het vorig jaar gedaan
Ben nu 2ejaars.

[Verwijderd]

FragDaddy schreef op maandag 26 september 2005 @ 14:54:
[...]


Schrijf jij maar eens een applicatie die bijvoorbeeld de communicatie van het OS naar de videokaart in de gaten houdt of een andere vrij diepe systeemfunctie / hardwaredrivers wil controleren/beheren.

windows heeft daar prachtige functies voor bedacht. ok ok die zullen vast niet voor elke functie/driver aanwezig zijn, maar dan nog wil je geen "monitoring" tools op kernel mode laten draaien.

[Verwijderd]

Verwijderd schreef op maandag 26 september 2005 @ 15:30:
Ik geloof dat jij het niet eens bent met de rest van de wereld. Lees voor de grap nu eens die definities door op die google pagina en je zult zien dat een oneindige lus aan geen enkele definitie voldoet.

Het is heel simpel. Het heet niets voor niets 'deadlock'. Dus een dood slot. Een slot wat ergens opgezet is, maar door het zettende proces er niet meer af gehaald (kan) worden.

_dat_ is een deadlock. Niets meer en niets minder.

Dat je voor een deadlock 2 processen en 2 resources nodig zou hebben, slaat helemaal nergens op, ook niet binnen jouw definitie.

Als je perse resources erbij wilt betrekken (wat dus echt niet nodig is voor een deadlock), dan is 1 resource voldoende. 2 resources en 2 processen is echt een antwoord wat kant nog wal raakt.

Als je bv. 2 threads hebt die gebruik maken van een 3e thread (voor bv. synchronisatie) en thread 1 locked die thread, wacht dan op thread2, terwijl thread2 wacht tot thread1 thread 3 unlocked, dan heb je gewoon een deadlock, zonder dat daar uberhaupt een resource bij betrokken is.

[Haan]

@hezik: je weet me nog steeds niet van je gelijk te overtuigen

nog ff een quote (uit The architecture of computer hardware and systems software, Irv Englander)

.. When one process has a resource(1) that another process needs to proceed, and the other process has a resource(2) that the first process needs, then both are waiting for an event that can never ocuur, namely, the release by the other process of the needed resource. This situation(waar dus het ene proces wacht tot een resource door het andere proces wordt vrij gegeven) can be extended to any number of processes, arranged in a circle. This situation is called a deadlock, ..

[ Voor 10% gewijzigd door Haan op 26-09-2005 20:10 ]

[Verwijderd]

Daar staat anders precies wat ik zeg. Note ook het feit dat ze het over 1 resource hebben, niet over 2. Zie ook dat hij aangeeft dat het ook met meerdere processen in een cirkelvormig iets kan, wat ik dus beschrijf, en waar dus helemaal geen resource bij komt kijken.

[ Voor 45% gewijzigd door Verwijderd op 26-09-2005 20:03 ]

[Haan]

Verwijderd schreef op maandag 26 september 2005 @ 20:02:
Daar staat anders precies wat ik zeg. Note ook het feit dat ze het over 1 resource hebben, niet over 2. Zie ook dat hij aangeeft dat het ook met meerdere processen in een cirkelvormig iets kan, wat ik dus beschrijf, en waar dus helemaal geen resource bij komt kijken.

Lees nog eens goed, misschien dat m'n extra toevoeging wat duidelijkheid schept.

[Verwijderd]

Je extra toevoegingen kloppen echter niet. Misschien moet je zelf wat beter lezen. Nergens staat dat de resource waar hij het over heeft, voor beide processen verschillend is. 'This situation' slaat niet op 'waar dus het ene proces..', maar op de term deadlock. Een deadlock kan ook voorkomen tussen drie threads, zonder dat er een resource bij betrokken is.

Voor een deadlock is echt geen resource nodig. Ook threads kunnen elkaar locken en unlocken, om maar wat te noemen. Maar ook een simpele variabele kan een lock op iets zijn.

Waarom denk je dat het een deadlock heet? Het is een lock op iets, maar de lock is, door slechte flow, dead.

[ Voor 12% gewijzigd door Verwijderd op 26-09-2005 20:17 ]

[RayNbow]

Verwijderd schreef op maandag 26 september 2005 @ 20:16:
Ook threads kunnen elkaar locken en unlocken, om maar wat te noemen. Maar ook een simpele variabele kan een lock op iets zijn.

En dat zijn geen resources dan?

(Resource: Something which is required to complete a task.)

[Verwijderd]

Als je het zo interpreteert, is alles een resource. Immers de thread is zelf ook nodig om die task te doen, dus ook een resource.

Binnen die (foute) definitie zou je dan zelfs kunnen zeggen dat een deadlock kan optreden bij louter 2 resources.

Een thread is geen resource.

[ Voor 7% gewijzigd door Verwijderd op 26-09-2005 20:22 ]

[RayNbow]

Verwijderd schreef op maandag 26 september 2005 @ 20:21:
Als je het zo interpreteert, is alles een resource. Immers de thread is zelf ook nodig om die task te doen, dus ook een resource.

Binnen die (foute) definitie zou je dan zelfs kunnen zeggen dat een deadlock kan optreden bij louter 2 resources.

Een thread is geen resource.

Een lock wordt trouwens altijd verkregen op een mutex. Als je wilt kunnen locken op thread niveau, dan heb je dus per thread een mutex (en zie je de threads dus als resources).

[Verwijderd]

Een lock wordt helemaal niet altijd verkregen op een mutual exclusion? Hoe kom je daar bij? Waarom is een thread een resource als er een mutex aan gekoppeld is?

Misschien het woord mutial exclusion eens opzoeken in het woordenboek? Een lock _kan_ een mutex zijn.

[ Voor 27% gewijzigd door Verwijderd op 26-09-2005 20:32 ]

[The Wrecker]

Verwijderd schreef op maandag 26 september 2005 @ 14:45:

Je hebt gewoon niet gelijk. Kijk naar een database. User a update veld x van waarde 1 naar 2. User b wil datzelfde veld updaten van waarde 1 naar 3. De database werkt met transacties. De transactie van user1 wordt als eerste verwerkt, de transactie van user2 zal als foutmelding een deadlock geven, omdat de uitgangspositie voor die transactie (veld x heeft waarde 1) niet meer bestaat.

Zodra proces1 iets verandert zodanig dat de uitgangspositie van proces2 niet meer klopt, kan er sprake zijn van een deadlock, zonder dat er een oneindige loop is.

Kijk je uit dat je geen race conditie hier neerzet?

/mijn versie van een deadlock:
proces1 lockt een resource1
proces2 lockt een andere resource2
proces1 wacht tot proces2 de resource2 vrijgeeft
proces2 wacht tot proces1 de resource1 vrijgeeft

beiden processen zullen nooit een process unlocken en blijven dus op elkaar wachten.

Een race conditie is net wat anders en heeft maar 1 resource nodig.
voorbeeld:
proces1 leest een waarde
proces2 leest dezelfde waarde
proces1 doet waarde+1 en schijft het weg
proces2 schrijft de waarde ook weg

Hier gebeurd er dus iets dat een 'nieuwe' waarde niet word meegenomen door proces2

@ hieronder
En dan heb je een race conditie met een qeue? Dat gaat toch goed ? Gebeurd verder niets mee hoor.

[ Voor 62% gewijzigd door The Wrecker op 26-09-2005 20:46 ]

[Verwijderd]

Een race condition is weer wat anders. Een race condition is bv. als je een queue hebt waar 1 thread van boven wat ingooit en een andere thread van onder weer wat uithaalt. Wat ik daar neerzette, was geen race condition.

[RayNbow]

Verwijderd schreef op maandag 26 september 2005 @ 20:31:
Een lock wordt helemaal niet altijd verkregen op een mutual exclusion? Hoe kom je daar bij? Waarom is een thread een resource als er een mutex aan gekoppeld is?

Ok ok... niet altijd, er zijn meerdere typen locks, dus niet altijd op een mutex.

Misschien het woord mutial exclusion eens opzoeken in het woordenboek? Een lock _kan_ een mutex zijn.

A mutual-exclusion locking object that allows multiple threads to synchronize access to shared resources. A mutex has two states: locked and unlocked. Once a mutex has been locked by a thread, other threads attempting to lock it will block. When the locking thread unlocks (releases) the mutex, one of the blocked threads (if any) acquires (locks) it and uses the resource. The thread that locks the mutex must be the one that unlocks it.

[Verwijderd]

RayNbow schreef op maandag 26 september 2005 @ 20:52:

Wederom quoot je precies wat ik al zei. Een mutex is een lock. Of, beter gezegd, een mutex is een van de vele locking mechanismes die er zijn.

[Haan]

Verwijderd schreef op maandag 26 september 2005 @ 20:16:
Je extra toevoegingen kloppen echter niet. Misschien moet je zelf wat beter lezen. Nergens staat dat de resource waar hij het over heeft, voor beide processen verschillend is. 'This situation' slaat niet op 'waar dus het ene proces..', maar op de term deadlock. Een deadlock kan ook voorkomen tussen drie threads, zonder dat er een resource bij betrokken is.

Tuurlijk staat dat er impliciet wel.. denk maar na: dit is wat jij nu zegt dat er staat:
'proces 1 is bezig met resource 1 -> proces 2 wacht tot resource 1 wordt vrijgegeven door proces 1 en dat gebeurt nooit.. '
Dat is dus niet waar zoals je waarschijnlijk wel inziet. Dus mijn quote gaat over meerdere resources anders klopt het niet wat er staat.

[Verwijderd]

Haan schreef op maandag 26 september 2005 @ 21:13:
@ hieronder
En dan heb je een race conditie met een qeue? Dat gaat toch goed ? Gebeurd verder niets mee hoor.

Dat kan goed gaan, afhankelijk van wat de functie van je queue is. Als het een queue is die niet leeg mag zijn bv, dan heb je wel degelijk een race condition.

Wat betreft resources.. lees het volgende eens:

process 1 locked een resource en vraagt iets aan process2, waarvoor process2 dezelfde resource moet locken.

Dat is geen race conditie, maar een doodordinaire deadlock.

Overigens gaan jullie uit van deadlocks die alleen kunnen ontstaan door een gebrekkige flow. Dit hoeft niet waar te zijn. Een deadlock kan ook ontstaan doordat bv. een thread, om wat voor reden dan ook, crashed en op die manier de lock niet meer vrijgeeft. Ook die lock is een deadlock.

Een deadlock is niet een duidingswijze voor een samenspel van verschillende factoren, het is geen design pattern ofzo. Een deadlock is gewoon een lock wat niet meer verwijdert wordt. Daarom heet het ook een deadlock.

Dat niet meer verwijderen kan door allerlei oorzaken, waarvan bad design er 1 is.

Stel ik lock in een database een row uit een table om er iets mee te doen, maar ergens in dat iets gaat er iets mis. Zeg, de persoon achter de computer killed de applicatie op dat moment, bijvoorbeeld omdat hij/zij het te lang vind duren. De lock is dan niet vrijgegeven en het proces wat hem vrij had moeten geven is er niet meer. Zie daar.. wederom een deadlock.

[ Voor 14% gewijzigd door Verwijderd op 26-09-2005 22:18 ]

[Verwijderd]

Verwijderd schreef op maandag 26 september 2005 @ 19:14:
Als je bv. 2 threads hebt die gebruik maken van een 3e thread (voor bv. synchronisatie) en thread 1 locked die thread, wacht dan op thread2, terwijl thread2 wacht tot thread1 thread 3 unlocked, dan heb je gewoon een deadlock, zonder dat daar uberhaupt een resource bij betrokken is.

*zucht* Hier gebruik je ook meerdere resources. Voor thread1 zijn de locks op thread2 en thread3 resources, en voor thread2 zijn de locks op thread1 en thread2 resources. Kijk als je het niet wilt snappen zeg het dan gewoon dan hoeven we deze discussie ook niet te voeren.

Maar goed, geef me eens een definitie (opgesteld door een onafhankelijke, authoritatieve 3e partij) waaruit blijkt dat een oneindige lus ook een deadlock is, en dat je een deadlock kan hebben zonder resources...

Eerst zeg je:

Verwijderd schreef op maandag 26 september 2005 @ 20:16:
Waarom denk je dat het een deadlock heet? Het is een lock op iets, maar de lock is, door slechte flow, dead.

En dan ineens:

Verwijderd schreef op maandag 26 september 2005 @ 22:16:
Overigens gaan jullie uit van deadlocks die alleen kunnen ontstaan door een gebrekkige flow..

Wij zijn diegene die jou ervan proberen te overtuigen dat (simpel gezegt) deadlock ontstaat doordat 2 (of meer) processen wachten op een resource. Jij beweert dat gebrekkige flow ook een deadlock is (wat dus niet zo is).

Verwijderd schreef op maandag 26 september 2005 @ 22:16:
Dit hoeft niet waar te zijn. Een deadlock kan ook ontstaan doordat bv. een thread, om wat voor reden dan ook, crashed en op die manier de lock niet meer vrijgeeft. Ook die lock is een deadlock.

Ware het niet dat elk modern OS die lock (en vrijwel alle andere resources) vrijgeeft zodra de applicatie/het proces/de thread crashed. Als er voor de crash een deadlock situatie was, zal dat na de crash niet meer zo zijn. De crash zelf veroorzaakt natuurlijk geen deadlock.

[Verwijderd]

Verwijderd schreef op dinsdag 27 september 2005 @ 09:31:
*zucht* Hier gebruik je ook meerdere resources. Voor thread1 zijn de locks op thread2 en thread3 resources, en voor thread2 zijn de locks op thread1 en thread2 resources. Kijk als je het niet wilt snappen zeg het dan gewoon dan hoeven we deze discussie ook niet te voeren.

Iets minder arrogant mag wel hoor. Jij bent hier diegene die het niet wil snappen. Je maakt van threads resources en vice versa al naar gelang jou het uitkomt. Een thread is geen resource, althans, dat kan wel, maar dat hoeft niet perse. Ik zie niet in waarom een lock uitgevoerd door een thread (zie de nuance met 'een lock OP een thread') een resource moet zijn voor een andere thread.

Maar goed, geef me eens een definitie (opgesteld door een onafhankelijke, authoritatieve 3e partij) waaruit blijkt dat een oneindige lus ook een deadlock is, en dat je een deadlock kan hebben zonder resources...

Tsja jouw redenatie is simpel. Als er geen resources bij voorkomen, dan benoem ik non-resources als resources. Als jij nu eens met een onafhankelijke 3e partij aankomt die zegt dat in door mij genoemde voorbeeld threads resources zijn?

Eerst zeg je:
En dan ineens:

Hoezo en dan ineens? Het een sluit het ander geenszins aan. Je quoot twee dingen die elkaar op geen enkele wijze tegenspreken, en komt dan met uitspraken als 'en dan ineens'. Dat slaat nergens op.

Wij zijn diegene die jou ervan proberen te overtuigen dat (simpel gezegt) deadlock ontstaat doordat 2 (of meer) processen wachten op een resource. Jij beweert dat gebrekkige flow ook een deadlock is (wat dus niet zo is).

Wat volgens jou dus niet zo is. Ik heb nog nergens iemand met een onafhankelijke bron zien komen die dit expliciet beweerd.

Ware het niet dat elk modern OS die lock (en vrijwel alle andere resources) vrijgeeft zodra de applicatie/het proces/de thread crashed. Als er voor de crash een deadlock situatie was, zal dat na de crash niet meer zo zijn. De crash zelf veroorzaakt natuurlijk geen deadlock.

Zo natuurlijk is dat niet en geen enkel modern OS geeft locks zomaar vrij, dat hangt toch echt van de lock af. Als ik zelf een lock ergens op implementeer, heeft het OS daar echt geen weet van hoor.

[ Voor 5% gewijzigd door Verwijderd op 27-09-2005 10:41 ]

[Verwijderd]

Goed, we gaan terug naar het begin:

Verwijderd schreef op zondag 25 september 2005 @ 17:20:
Wederom een foute vraag, of althans, foute antwoorden. Een deadlock kan al optreden met 1 proces en geen resource.

Daar ben ik (en zo te lezen aan de reacties, ook vele anderen) het niet mee eens. Zie:

http://en.wikipedia.org/wiki/Deadlock
In the computing world deadlock refers to a specific condition when two processes are each waiting for the other to release a resource, or more than two processes are waiting for resources in a circular chain (see Necessary conditions). Deadlocks are a common problem in multiprocessing where many processes share a specific type of mutually exclusive resource known as a lock. They are particularly troubling because there is no general solution to avoid deadlocks.

http://www.gnu.org/softwa...l/html_node/Glossary.html
Deadlock
The situation in which two communicating processes are each waiting for the other to perform an action.

http://hea-www.harvard.ed...ql/glossary/glossary.html
deadlock
a pathological state of a computer system reached when none of a group of competing processes can proceed because each is waiting for resources locked by the other(s).

http://docs.hp.com/en/32650-90887/ch01.html
deadlock

A condition that arises when multiple processes are waiting for resources held by other processes. A process cannot release the resources it holds until it can acquire the resources it is waiting for, but it cannot acquire these resources until another process releases them.

http://docs.rinet.ru/KofeynyyPrimer/ch38.htm
deadlock Deadlock occurs when two or more threads are waiting for resources that they can't get. An example would be when one thread must access Method1 before it can release its hold on Method2, but the second thread must access Method2 before it can release its hold on Method1. Because these are mutually exclusive conditions, the threads are deadlocked and cannot run.

Zoals je ziet zeggen al deze definities hetzelfde, namelijk dat er tenminste 2 processen zijn en dat deze wachten op een resource die door een ander proces vastgehouden wordt. Dit is dus in directe tegenspraak met jouw opmerking dat er maar 1 proces hoeft te zijn en helemaal geen resource(s).

Mocht je het hier nog steeds niet mee eens zijn, dan ben ik benieuwd wat volgens jouw de definitie van deadlock is...

[ Voor 3% gewijzigd door Verwijderd op 27-09-2005 12:43 ]