1

Onderwerp: multithread advisory locking

Ik heb de volgende situatie geknutseld:

Een daemon luistert op een poortje voor inkomend berichten.
Zodra er een bericht binnen komt splitst het proces zich af (vfork) en moet het volgende gebeuren.
- In een tabel wordt een status gebasseerd op een aan het bericht gekoppelde entry aangepast.
- Er wordt een verwerk process aangeroepen dat ALLE in de tabel gemarkeerde berichten afhandeld
Echter dit verwerk process mag niet meerdere malen tegelijk worden opgestart,

Nu heb ik daar voor het volgende bedacht.
- Het geforkte process maakt een advisory lockfile aan. en start de verwerker op.
- De verwerker haalt de lockfile weer weg.
- Indien het geforkte process de lockfile ziet, markeert het wel de status maar roept de verwerker niet aan.

Daar het mogelijk moet zijn om de verwerker met de hand op te kunnen starten heb ik het aanmaken van de lockfile
daar niet onder gebracht, maar wel het verwijderen.
Op deze manier zorg ik er voor dat een lockfile die het systeem vast laat hangen verwijdert wordt simpel weg door het verwerker proces op te starten.

--- Het probleem ---
Deze manier van werken lijkt me redelijk veilig, maar ik loop het risico dat bij bulk berichten het laatste process pas verwerkt wordt als er een nieuw bericht binnen komt (dat zal zo'n twee uur later zijn)
Immers als de verwerker loopt waneer het laatste bericht op d edaemon binnenkomt en het gemarkeerde bericht niet wordt opgepakt (omdat dit in de lijst al gepaseerd is, een heel rieele situatie)  dan gebeurd er daarna niets meer.

Ik zoek dus een manier om dit verhaal waterdicht te krijgen.

Pascal's Blobfree Homepage
Een dag geen NedLinux is een dag niet geleefd

2

Re: multithread advisory locking

de verwerker opnieuw de lijst door laten lopen net zolang tot hij een run heeft gemaakt zonder wijzigingen?

Peter (aka Bilbo) geeft geen garantie op bestand- en padnamen, hij doet aan tab-completion.
http://bilbos-stekkie.com

3

Re: multithread advisory locking

goed plan.
niet aan gedacht, eigenlijk heel logisch...
eens kijken of dat niet te lastig is om te implementern... denk dat het wel mee valt.
tnx !

Pascal's Blobfree Homepage
Een dag geen NedLinux is een dag niet geleefd

4 Laatst bewerkt door QzZRBNMdJdsCmwx (26 Aug 2014 18:14:52)

Re: multithread advisory locking

De beschrijving is niet echt specifiek genoeg om veel te kunnen zeggen, maar...

De gewoonlijke manier om dit soort problemen op te lossen in de worker als een continue draaiend proces te hebben die blokkeert op een queue (als er een element in de queue is, kan de worker aan het werk). Het server proces gooit dan werk op de queue.

File system locking levert al snel allerlei problemen op. Als je een extra proces kunt draaien, zou je iets als Redis kunnen gebruiken. Een Redis lijst is tegelijkertijd ook een queue (bijv. via het BLPOP commando). Je kunt de server dus een taak op een Redis lijst laten zetten en dan de worker laten blokkeren op dezelfde lijst. Zodra er dus iets op de lijst binnenkomt, kan de worker aan de slag gaan. Het voordeel is dat je ook persistentie hebt (als de worker tijdelijk weg is, wordt werk gewoon opgeslagen in de queue).

Met zeromq kun je ook dit soort dingen op een lager niveau doen, gewoon in C, embedded in je applicatie.

Uiteraard zijn de nette benaderingen lastiger als het proces dat je wilt uitvoeren een een of ander obscuur shell script of proprietary binary is. Maar dan nog kan de worker een simpele wrapper zijn die een fork + exec doet en dan een waitpid op het child proces (zodat het programma maximaal één keer uitgevoerd wordt).

Bilbo's benadering werkt ook, maar heeft het gevaar dat als de worker crasht op een bepaalde input, het oneindig dezelfde input weer opnieuw doet, dus je moet op tijd markeren dat je het werk gedaan hebt (ofterwijl, de lijst als een propere queue gebruiken). Verder moet natuurlijk de lijst veilig zijn voor concurrent updates. Again, te weinig details om daar iets zinvols over te kunnen zeggen.

5

Re: multithread advisory locking

Dank voor je reactie Daniel

Ik zou er een tekeningetje bij kunnen maken maar eigenlijk is het niet lastiger dan ik aangeef.
We praten hier niet over raketwetenschappen maar gewoon over gegevens uitwisseling en verwerking.
Toegegeven het hoe en waarom het hele plaatje is voor een leek wat lastig te volgen maar voor een ICT man niet zo heel spectaculair

- Het is om een aantal reden NIET de bedoeling dat de 'worker' continu blijft draaien.
Dit programma is overigens ook gewoon user opstartbaar, het heeft meerdere functies, zoals bv raportage.

- Er is bij ons niets propritary/binary alles is uit eigen keuken.
Waar ik wel rekening mee moet houden is dat het spul niet op een Linux bak draaid maar op HP-UX en dat is toch even anders.
Gelukkig heb ik erg veel ervaring met een zeer uitgebreid scala aan verschillende besturings systemen dus dat loopt wel los.

Pascal's Blobfree Homepage
Een dag geen NedLinux is een dag niet geleefd

6

Re: multithread advisory locking

Als je het simpel wil houden, kan je evengoed wel iets van Daniel gebruiken: hou de status bij in die queue... geef aan dat er een bewerking is begonnen. Komt de verwerker die status tegen dan weet hij dat er stront aan de knikker is en kun je aktie ondernemen.

Peter (aka Bilbo) geeft geen garantie op bestand- en padnamen, hij doet aan tab-completion.
http://bilbos-stekkie.com

7

Re: multithread advisory locking

Peter dat is al het geval he
De daemon zet van elk record met de status van 20 (VERSTUURD) en ook enkel die, naar 21 (OPHALEN)
en de verwerker zet ehm vervolgens in status 30 (OPGEHAALD)
Dat is dus allemaal wel dicht getimmerd.
Het probleem is (was) dus dat waneer de laatste kick wordt gegeven als de verwerker al draait en het betreffende record al geweest is (louter academische situatie) dan mis ik dus een verwerking totdat we weer een paar uur verder zijn.
Op zich werkt te hele boel goed.

Pascal's Blobfree Homepage
Een dag geen NedLinux is een dag niet geleefd

8

Re: multithread advisory locking

academische situaties ROFL

die ken ik... het zijn die academische situaties die broodjes pindakaas met de pindakaas naar beneden op je hoogpolige tapijt laten vallen....

Peter (aka Bilbo) geeft geen garantie op bestand- en padnamen, hij doet aan tab-completion.
http://bilbos-stekkie.com

Re: multithread advisory locking

Ik weet dat het om de eigen software gaat, maar toch grappig wink:


pascal schreef:

- Er is bij ons niets propritary/binary [...] draaid maar op HP-UX en dat is toch even anders.

10

Re: multithread advisory locking

wink

Pascal's Blobfree Homepage
Een dag geen NedLinux is een dag niet geleefd

11

Re: multithread advisory locking

Je titel is: multi-thread advisory locking

Je schreef:"Een daemon luistert op een poortje voor inkomend berichten. Zodra er een bericht binnen komt splitst het proces zich af (vfork) ...."

Zoals je zegt, een fork; een apart proces terwijl verschillende threads binnen 1 proces lopen. Dus je titel verwart n beetje.

12

Re: multithread advisory locking

Je hebt gelijk George.
Ik zou het echter niet beter weten te omschrijven.
Wij maken niet echt multithreaded spul maar gewoon forks..  en eigenlijk alleen maar voor dit soort daemon achtige dingen
die bovendien hun ding gewoon zelf afwikkelen...
wat ik doe (en niets voorsteld) is al een buitenbeentje.
Maar goed ik doe wel meer dingen anders dan mijn colega's... b.v. door de nood gedwongen OOP in C.. doen ook niet zo heel veel mensen maar gaat eigenlijjk prima wink

Pascal's Blobfree Homepage
Een dag geen NedLinux is een dag niet geleefd

Re: multithread advisory locking

pascal schreef:

Je hebt gelijk George.

Hangt er vanaf welke versie van Linux je gebruikt. Linux versies die LinuxThreads gebruikten, gebruikten een proces per thread (met een gedeelde address-space), dus de stelling:

Zoals je zegt, een fork; een apart proces terwijl verschillende threads binnen 1 proces lopen.

Is niet per definitie waar wink.

Maar goed ik doe wel meer dingen anders dan mijn colega's... b.v. door de nood gedwongen OOP in C.. doen ook niet zo heel veel mensen maar gaat eigenlijjk prima wink

Best veel mensen - glib en dus bij extensie gtk+ en GNOME. Maar je vraagt je je soms af waarom je het zou willen doen wink.

14

Re: multithread advisory locking

Daniel. zoals ik aangaf, we gebruiken geen Linux (althans niet op die plek)

Waarom je OOP in C zou willen doen.
Nu dat ligt er een beetje aan met welke insteek je die vraag stelt.
Ik zal iig antwoord geven op mijn insteek en de rest even laten voor wat het is.

Ik moet een hoop data op verschillende niveas verzamelen teneinde die als een pakket te kunnen doorverwerken.
Na een aantal mislukte pogingen die voornamelijk te maken hadden met het sequentieel lezen karakter van alle informatie die ik binnen krijg en die totaal andere volgorde en hoeveelheid die ik moet verwerken kwam ik uiteindelijk tot de conclussie dat ik de hele rotzooi maar in gelinkte lijsten van gelinkte lijsten van gelinkte lijsten (ik meen zo uit mijnhooft 4 levels) te zetten.

Dit hele gedoe gebeurd ook nog eens op verschillende plaatsen, en zo werdt bij aanpassingen de kans al vrij groot dat er memory leaks onstonden (lang leve valgrind)
Dus begon ik met iets in de stijl van

typedef struct coole_struct
{
      char   *Naam;
      char   *Reference;
      daniel_struct *Daantje;
      struct coole_struct *Next;
} coole_struct;

struct coole_struct *coole_New();
void coole_List(coole_struct *coole);
void coole_Destroy(coole_struct *coole, int recursive);

Niet heel bijzonder.
Maar daar ik ook allerlij ander spul moest maken begon ik steeds meer dit idee te handhaven om met een OOP gedachte mijn code te schrijven.
Waarom dan gewoon een CPP compiler gebruiken... welnu dat zou in mijn geval kunnen, maar ik weet niet of ik dan issues krijg met libs die in C geschreven zijn en eigenlijk vind ik dit prima zo. heel veel meer dan classes (structures dus) heb ik voor dit project niet nodig.
En dat geld eigenlijk voor allerlij andere zaken die ik in dit kader aan het bakken ben.

Ik begrijp dus wel je insteek, maar deel je impliciete (afkeurende) waarde oordeel van deze werkwijze niet.

Feit is overigens dat ik door mijn aanpak zaken ineens een stuk sneller, zeer zeker overzichtelijker en vooral beheerbaarder kan ontwikkelen.
Daarbij heb ik alles ook nog eens gedocumenteerd (wie doet dat nog vandaag de dag) dus elke gekwalificeerde developer (als die nog te vinden zijn) kan mijn klus overnemen.

Daarom dus.

Pascal's Blobfree Homepage
Een dag geen NedLinux is een dag niet geleefd

Re: multithread advisory locking

Mijn opmerking was onder meer omdat OO in C pijnlijk is vergeleken met bijvoorbeeld C++. Als we het over bijv. memory leaks hebben, in C++ kun je RAII gebruiken en hoef je nooit meer handmatig deallocaties te doen of resources te sluiten. Uiteraard zonder meteen een garbage collector te gebruiken wink. En zelfs als je geen overerving gebruikt, zijn dingen als abstract base classes toch handig om interfaces te kunnen definiëren.

C libraries aanroepen in C++ is geen enkel probleem. C++ libraries vanuit C aanroepen kan ook prima, maar dan moet je een kleine wrapper maken met C linkage. Bijv:

https://github.com/rug-compling/alpinoc … pus/capi.h
https://github.com/rug-compling/alpinoc … c/capi.cpp

16

Re: multithread advisory locking

@danieldk
Correct: .... niet per definitie waar ... maar LinuxThreads is al jarenlang obsolete

17

Re: multithread advisory locking

Sjorsje, Pascalleke moet die meuk op een HP-UX bak draaiend krijgen he wink
Maar goed. dat is Morgen pas. nu is de dag des here en hebben we andere bezigheden.

Pascal's Blobfree Homepage
Een dag geen NedLinux is een dag niet geleefd

18

Re: multithread advisory locking

Gaar het lukken (genieten van de dag des Here), maw, heb je het probleem opgelost ?

19

Re: multithread advisory locking

Met een colega over gehad, de oplossing kan nog veel simpeler !
Gewoon de verwerker na elk record van voren af aan opnieuw laten beginnen, ipv laten lopen
De database read functie geeft een 0 terug als er geen record meer wordt gevonden waaraan voldaan moet worden.
Daar het maar om zeer weinig records gaat (elke keer max een stuk of honderd) is performance (steeds opnieuw beginnen te zoeken) geen issue.
Enige wat ik hoef aan te passen is een enkel commando dat ipv Next   steeds weer First gaat zoeken.
Nu nog eens tijd vinden... nog veel andere klussen te doen..

Pascal's Blobfree Homepage
Een dag geen NedLinux is een dag niet geleefd