process/threads/childen?

Ved brug af Threads har du mulighed for nemmere at styre de forskellige tråde. Da du kan stoppe/pause/sleep ved en enkelt kommando fra selve \"grund processen\". Der ud over er der lidt (ikke meget) plads fordel, i form af diverse programvariable deles.
Dette gøres de ikke ved childprocesses, da dette er en proces for sig selv, der intet har med far processen at gøre (også i forbindelse med variable og hukkommelsesområde mm.) bort set fra at den er blevet sat i gang af denne.

Såfremt at du skal kontrollere tilgangen til databasen ved hjælp af låse (semaforer), for at undgå diverse database anomelies er det lige meget hvad du bruger. Hvis du ikke har behov for at styre de forskellige tråde/children er det efter min mening ligegyldigt.

Det skal dog lige siges, at der kan være en forskel med hensyn til hvor meget cpu tid dit program for tildelt. på grund af mængden af processer. (dette gælder blandt andet hvis der køres et unix -system f.eks linux)

eks. situation programmet kører på en server hvor der er 5 ligestillede processer dvs. at hver proces får 1/5 af cpu-tuden. databaseprogrammet er en af disse processer.


Bruges der tråde, vil databasesystemet stadig kun have 1/5 del af cpu-tiden, hvor denne tid så bliver delt ud på hver af de enkelte tråde efter tid. dette er lige gyldigt hvor mange tråde der er

Bruges der der i mod children og der f.eks 5  \"børn\", vil hver proces nu have 1/10 af cpu tide. DVS. af databasesystemet nu har 6/10 del af al cpu-tiden.

Så er man lige glad med de andre programmer der eventuelt skal kører på serveren, er det ud fra et selvisk synspunkt en fordel af bruge children.

hvis jeg antager at en childprocess er uafhændig af parrentprocessen hvordan kan med så låse tableafgangen (semaforisk)?,ved en tråd har jeg jo mulig for globale varialber(mutex),kan man så ikke bruge mutexlåse i en childprocess ??

Sagtens: Måden hvorpå semaforen virker er, at det er styresystemet (kernen) der sørger for kontrollen tilgang til den \"krtiske region\".

Det der sker når du har en mutex semafore, for hele databasen (eller en del) er følgende.
((mutex)semaforen er initialiseret til 1)
Det første en proces gør inden den skal tilgå den kritiske region er at den prøver at tælle metaforen ned - det kan den kun hvis metaforen er større en nul - hvis den kan det, går den ind i den kritiske region. Det sidste processen gør efter at være færdig med den kristiske region er at tælle semaforen op. Sker der i mellemtiden det, at en anden proces også prøver at tilgår den samme kritiske region vil denne blive lagt til at sove af styresystemet, når den prøver at tælle mutex-semaphoren ned (denne er jo 0 i forvejen og kan ikke tælles længere ned).
Når den første proces så tæller semaforen om, bliver nr. 2 proces vækket op, og kan tælle semaforen ned ovs.

Såfremt du bruger findelte låse på din database, så sørg for at designe det sådan, at du undgår deadlock (bare en remeinder :-) ).

Det skal lige for en ordens skyld lige siges, at jeg kun har erfaring med C og ikke C++, mine erfaringer med tråde stammer fraJava, så hvordan C++ håndtere semafore ved jeg ikke, men jeg går ud fra at de findes. Siden du taler om tråde, går jeg næsten ud fra at det er C++ du sider og roder med ;-)

hvis jeg nu vil tillade at have flere read processer inde i tabelleren afgangen men ved update kun en process.kan en mulig teroisk løsning så være således:

if(s2==1)//kun hvis ingen er ved at læse.
wait(s1);
//update table.
signal(s1);

if(s1==1)//kun hvis inge er ved at update.
signal(s2);
// read table.
wait(s2);

det driller mig lidt..og jo c++ på linuxplatform. det er ikke verdens nemmeste platform at arbejde på.

Jeg kan ikke lige gennemskue det du vil der
!!

En måde at løse det på, er at have 1 mutex-variable/semaforer,og så en der tæller antallet læseprocesser.

Den første læseproces der kommer tæller mutex sematoren ned og tælleren en op. de efterfølgede læseprocesser der kommer til samtidigt, tæller blot tælleren 1 op. Når læse procsserne forlader databasen skriver de tælleren en ned, den sidste der forlader databasen tæller også mutexsemaforen 1 op, så databasen kan blive åben for skriveprocesser.

Når der kommer en skriveproces, prøver denne at tælle mutex semaforen ned. Hvis der ikke er nogen læseprocesser/eller skriveproceser fortsætter den blot. Er der en skriveproces/en eller flere læsesprocesser, må den vente.

På denne måde er det dog læseprocesserne der har første prioritet, da skriveprocessen ikke kan komme til så længe der bliver ved med at komme nye læseprocesser.