threading win32 api (windows ce)

[carbidsjitter]

Hallo iedereen,

Ik ben bezig met een industriele applicatie. In het kort komt het erop neer dat ik een joystick met uitlezen en de waardes van de joystick versturen via de canbus.

Nu heb ik in de c++ code een klasse gemaakt voor de joystick.

In deze klasse heb ik een functie 'update'. Hierin worden de analoge voltages opgevraagd en deze worden na omrekening in een variabele gestopt (bv x-as)

Ik ben van plan deze functie in een 'high priority' thread uit te voeren. Deze thread moet dan elke 1/100 seconde uitgevoerd worden.

Ook heb ik in de klasse joystick een functie 'get_x', deze returnt de x waarde van de joystick.
Deze functie kan in principe altijd opgevraagd worden.

Nu is mijn vraag:

Kan er een conflict onstaan wanneer tegelijkertijd in de thread de x-as waarde geschreven wordt en de x-as waarde bijvoorbeeld in de main (of andere functie) opgevraagd wordt.

en zoja, Hoe kan ik dit voorkomen ?

Ik heb al het een en ander gelezen over threads bij een win32 systeem.

Zover ik nu weet heb ik de volgende opties:

Event Objects
Mutex Objects
Critical Section Objects
Semaphores

Iemand hier ervaring mee? of een goede link met uitleg?

[.oisyn]

http://msdn.microsoft.com/en-us/library/ms684122(VS.85).aspx

Simple reads and writes to properly-aligned 32-bit variables are atomic operations. In other words, you will not end up with only one portion of the variable updated; all bits are updated in an atomic fashion.

[leuk_he]

carbidsjitter schreef op donderdag 22 april 2010 @ 11:29:
.

Nu is mijn vraag:

Kan er een conflict onstaan wanneer tegelijkertijd in de thread de x-as waarde geschreven wordt en de x-as waarde bijvoorbeeld in de main (of andere functie) opgevraagd wordt.

en zoja, Hoe kan ik dit voorkomen ?
.

De vraag: is de waarde van de x as in 1 cpu instrcutie geschreven, is het atomair? Ik vermoed van wel aangezine dat een int32 is?

Echter als je X en Y uitleest dan zie je dat de X door de andere thread geudpdate kan zijn maar de Y nog niet (ofzo). Voor een joystick zal dat niet veel uitmaken, als je dat maar niet met mijn bankrekening doet, of andere meer gecompilceerde data met afhankelijkheden.

Dan ga je om het lezen en schrijven een critical section zetten zodat maar 1 thread thegelijk die data benaderd.


Verder kan het handig zijn de variable volatile te definerern omdat anders de compiler kan besluiten dat de variable te cachen in een register, waardoor hij de updates uit de andere thread niet ziet.

Is pollen van de joystick zo traag/blocking dat het in een andere thread moet?

[.oisyn]

leuk_he schreef op donderdag 22 april 2010 @ 11:52:
Verder kan het handig zijn de variable volatile te definerern omdat anders de compiler kan besluiten dat de variable te cachen in een register, waardoor hij de updates uit de andere thread niet ziet.

Dat niet alleen, volatile zorgt er bij de gangbare compilers ook voor dat er een strictere ordering plaatsvindt. Bij een write naar een volatile variabele moeten alle voorgaande acties al hebben plaatsgevonden, en bij een read van een volatile mogen acties die erna volgen niet vóór de read plaatsvinden. Gebruik je geen volatile, dan mag een compiler naar hartelust de acties herordenen zolang dat de observable state voor de huidige thread maar niet beïnvloedt.

Overigens lost het nog geen instruction en memory reordering door de CPU op, daarvoor zul je MemoryBarrier() (wat tevens als compiler barrier fungeert) moeten gebruiken. Maar goed, dat is voor dit probleem allemaal niet zo relevant.

[carbidsjitter]

Bedankt voor jullie antwoorden

leuk_he schreef op donderdag 22 april 2010 @ 11:52:
[...]De vraag: is de waarde van de x as in 1 cpu instrcutie geschreven, is het atomair? Ik vermoed van wel aangezine dat een int32 is?

x-as is gedefinieerd als een signed int (16 bit). Ik weet niet hoe de compiler daar mee omgaat.

Dus als de compiler hier een hele register voor gebruikt en ik definieer hem als volatile hoef ik me nergen zorgen om te maken ? (misschien een iets te snelle conclusie)

leuk_he schreef op donderdag 22 april 2010 @ 11:52:
[...]Is pollen van de joystick zo traag/blocking dat het in een andere thread moet?

Dat heb ik niet geprobeerd. Maar ik had threads in gedachten, omdat het uitlezen van de joystick moet
gebeuren. Denk ook aan kabelbreuk, of de gebruiker haalt de stekker van de joystick los terwijl de machine loopt.

Volatile gebruik ik ook in de c programmering. Dat is de enige manier om een waarde van een interrupt in je main te gebruiken zonder dat deze weg wordt geoptimaliseerd door de compiler.

Ik moet wel zeggen dat dit m'n eerste grootte c++ project is.

Voordat ik dit topic opende zat ik zelf te denken aan mutex aan de hand van dit voorbeeld http://msdn.microsoft.com...ry/ms686927(v=VS.85).aspx

Dus zowel in de thread als het opvragen van de variabele controleren of de mutex vrij is en dan pas de benodigde bewerkingen uit voeren.

Ik hoop door dit topic er achter te komen wat het beste is.