LOCK_EX vs LOCK_SH

Le
Sébastien Cottalorda
Bonjour a tous,

J'ai developpé un contrôle d'accès pour gérer les entrées/sorties=
de
parkings.

Le noyau du système (qui doit être temps réel) travaille avec le
module IPC::Shareable pour accéder très rapidement aux données mises
en mémoire.

Lorsqu'il y accède, il locke le(s) segment(s) de mémoire partagée
grâce à un LOCK_EX afin que les données qu'il va lire ne soient pas
corrompues durant sa prise de décision.

Seulement voilà durant le lapse de temps, tous les petits programmes
"clients" qui sont censé lire le contenue de la mémoire afin d'en
afficher le contenue se trouvent figés jusqu'à la libération du lock
ce qui peut être assez génant.
Je ne peux pas tous les mettre en LOCK_SH|LOCK_NB sinon ils ne lisent
même pas le segment puisque cela rend la main tout de suite.

Aussi, je me demandais si le noyau utilisait un LOCK_SH est-ce que
cela ne serait pas mieux ?

En fait, je voudrais idéalement que le programme principal puisse lire
et écrire, et que les programmes clients puissent seulement lire.

Est-ce que le LOCK_SH pourrait me tirer d'affaire ?

Sinon, comment puis-je régler ce problème ?

Merci d'avance pour votre aide.

Sébastien
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Emmanuel Florac
Le #146800
Le Fri, 15 Jun 2007 07:51:37 +0000, Sébastien Cottalorda a écrit :


Sinon, comment puis-je régler ce problème ?


Utilise un système adapté pour gérer les données, comme une base de
données?

--
Désormais, pour les nations et pour les peuples, une goutte de pétrole
a la valeur d'une goutte de sang.
Georges Clémenceau.

Paul Gaborit
Le #146799
À (at) Fri, 15 Jun 2007 10:24:59 +0200,
Emmanuel Florac
Le Fri, 15 Jun 2007 07:51:37 +0000, Sébastien Cottalorda a écrit :


Sinon, comment puis-je régler ce problème ?


Utilise un système adapté pour gérer les données, comme une base de
données?


Si l'impératif est d'obtenir de grandes performances (ce qui
justifierai le partage mémoire entre processus ou threads), je ne
pense pas que la base de données soit adpatées.

Ce que je ne comprends pas dans la problématique exposée, c'est que,
s'il n'y a qu'un seul écrivain, il n'y a que lui qui a besoin de faire
des locks et uniquement lorsqu'il écrit. Pour éviter de long blocage
lors de l'écriture, il lui suffit de préparer toutes ses données à
l'avance (il peut le faire sans lock puisqu'il n'y a que lui qui
modifie les données) et de les écrire d'un seul coup (durant un LOCK).

--
Paul Gaborit - Perl en français -

Sébastien Cottalorda
Le #146798
On 15 juin, 11:06, Paul Gaborit
À (at) Fri, 15 Jun 2007 10:24:59 +0200,
Emmanuel Florac

Sinon, comment puis-je régler ce problème ?


Utilise un système adapté pour gérer les données, comme une bas e de
données?


Si l'impératif est d'obtenir de grandes performances (ce qui
justifierai le partage mémoire entre processus ou threads), je ne
pense pas que la base de données soit adpatées.


C'est le cas.
Sinon, ce serait rigolo les jours de facture aux entrée et aux sorties
(sgbd assez chargé ...)

Ce que je ne comprends pas dans la problématique exposée, c'est que,
s'il n'y a qu'un seul écrivain, il n'y a que lui qui a besoin de faire
des locks et uniquement lorsqu'il écrit. Pour éviter de long blocage
lors de l'écriture, il lui suffit de préparer toutes ses données à
l'avance (il peut le faire sans lock puisqu'il n'y a que lui qui
modifie les données) et de les écrire d'un seul coup (durant un LOCK).

--
Paul Gaborit - Perl en français -

Le noyau, selon mes mesures locke au maximum 1 sec le(s) segment(s)
pour chaque évènement.

Hélas, il n'est pas tout seul pour plusieurs raisons:
* Il y a plusieurs parkings à gérer : les évènements lui arrive en
parallèle, en effet, sur le nombre de borne entrée/sortie, il se peut
tout a fait qu'il y ait plusieurs véhicule souhaita,t entrer ou sortie
simultannément.
* Chque prise de décision doit être atomique : lecture + décision
+ écriture ce qui conduit à un lock de ~ 1sec/évènement important
(0,00... sec pour des évènements peu importants),
* Le noyau n'est pas tout seul à écrire dans les segments de
mémoire, même si cela est vrai dans 98% des cas, il faut bien pouvoir
modifier les données permettant le contrôle d'accès : le nom d'un
client, ses données de facturation, ou tout bêtement modifier les
paramètres des équipements sans avoir à relancer tout le système de
contrôle d'accès (on peux faire mieux que Windows n'est-ce pas ?)

Lorsque le système est très chargé, je fini par avoir un embouteillage
au niveau des sémaphores, à ce moment là, tous les processus partent
en timeout.

C'est pourquoi, au niveau des programmes clients n'effectuant qu'une
lecture, j'ai également ajouté une tempo au delà de laquelle il
meurent.

En fait j'utilise LOCK_EX pour les processus chargés de lire et
*d'écrire*, et LOCK_SH pour les processus en lecture + mode bloquant
et LOCK_SH|LOCK_NB pour les programmes chargés uniquement de
l'affichage dont on peut se passer (puisqu'ils seront sollicités un
peu plus tard : si on perd un affichage, ce n'est pas dramatique).

Est-ce que j'ai bon ???

merci de votre temps et de votre aide.



Mark Clements
Le #146681
Sébastien Cottalorda wrote:
On 15 juin, 11:06, Paul Gaborit
À (at) Fri, 15 Jun 2007 10:24:59 +0200,
Emmanuel Florac
Sinon, comment puis-je régler ce problème ?
Utilise un système adapté pour gérer les données, comme une base de

données?
Si l'impératif est d'obtenir de grandes performances (ce qui

justifierai le partage mémoire entre processus ou threads), je ne
pense pas que la base de données soit adpatées.


C'est le cas.
Sinon, ce serait rigolo les jours de facture aux entrée et aux sorties
(sgbd assez chargé ...)


Est-ce que t'as regardé quelque chose un peu plus high-level que la
memoire partagé, par exemple BerkeleyDB?

http://www.oracle.com/database/docs/Berkeley-DB-v-Relational.pdf
http://search.cpan.org/~pmqs/BerkeleyDB-0.31/BerkeleyDB.pod

Normalement c'est performant et peut gèrer le locking etc soi-même.


Marl




Jérémy JUST
Le #146680
Le Fri, 15 Jun 2007 09:45:07 -0000,

Utilise un système adapté pour gérer les données, comme une base
de données?
Si l'impératif est d'obtenir de grandes performances (ce qui

justifierai le partage mémoire entre processus ou threads), je ne
pense pas que la base de données soit adpatées.
C'est le cas.

Sinon, ce serait rigolo les jours de facture aux entrée et aux sorties
(sgbd assez chargé ...)


Pour mon information, tu as fait des tests avec un SGBD genre
Postgresql? C'est réellement moins performant que ton système?

Parce que dans mon expérience (table avec deux à trois millions
d'enregistrements), la différence n'est pas si franche. J'ai comparé
deux systèmes:
- un hash maintenu en mémoire par un démon en Perl, à qui on adressait
des requêtes par un socket (client en Perl),
- une bête table sous Postgresql, indexée.

Pour une requête sur la clef du hash, le démon en Perl était plus
rapide d'un facteur 2 à 3. Pour des requêtes ne portant plus sur la
clef du hash, il fallait créer un second hash à côté, ce qui doublait
presque la RAM utilisée et donnait des performances proches de celles
Postgresql.
La différence principale était au moment du remplissage des
structures: il suffisait de quelques minutes pour remplir le hash avec
les 3 millions d'enregistrements, à partir d'un fichier tabulé, tandis
qu'il fallait une à deux heures pour Postgresql.


Voyant ces chiffres, j'ai du mal à imaginer que des entrées/sorties de
parkings puissent saturer l'un ou l'autre des systèmes. Par contre,
utiliser un SGBD te soulagerait de bien des soucis pour les
verrouillages et le partage entre processus.


--
Jérémy JUST


Emmanuel Florac
Le #146679
Le Sun, 17 Jun 2007 15:30:46 +0200, Jérémy JUST a écrit :

Voyant ces chiffres, j'ai du mal à imaginer que des entrées/sorties de
parkings puissent saturer l'un ou l'autre des systèmes. Par contre,
utiliser un SGBD te soulagerait de bien des soucis pour les verrouillages
et le partage entre processus.


C'est bien pour cela que j'en avais parlé :)

--
Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir
aristocratique de déplaire.
C. Baudelaire.

espie
Le #146678
In article Jérémy JUST
Pour une requête sur la clef du hash, le démon en Perl était plus
rapide d'un facteur 2 à 3. Pour des requêtes ne portant plus sur la
clef du hash, il fallait créer un second hash à côté, ce qui doublait
presque la RAM utilisée et donnait des performances proches de celles
Postgresql.
La différence principale était au moment du remplissage des
structures: il suffisait de quelques minutes pour remplir le hash avec
les 3 millions d'enregistrements, à partir d'un fichier tabulé, tandis
qu'il fallait une à deux heures pour Postgresql.


Et encore, c'etait avec du postgresql... sur certains types de tables,
je soupconne que sqlite va nettement plus vite, vu qu'il y a moins de
transferts a faire.

Et aussi, penser a virer l'autocommit, et a faire des commits manuels
toutes les 1000 ou 2000 transactions... Ca fait facilement un facteur
dix d'ecart sur la vitesse d'ecriture.

Jérémy JUST
Le #146677
Le Sun, 17 Jun 2007 14:35:34 +0000 (UTC),

Et aussi, penser a virer l'autocommit, et a faire des commits manuels
toutes les 1000 ou 2000 transactions... Ca fait facilement un facteur
dix d'ecart sur la vitesse d'ecriture.


En plus, gérer manuellement les commits donne une façon simple et
propre de réaliser des transactions atomiques. Que des avantages!


--
Jérémy JUST
Sébastien Cottalorda
Le #146674
On 17 juin, 10:20, Mark Clements wrote:
Sébastien Cottalorda wrote:
On 15 juin, 11:06, Paul Gaborit
À (at) Fri, 15 Jun 2007 10:24:59 +0200,
Emmanuel Florac
Sinon, comment puis-je régler ce problème ?
Utilise un système adapté pour gérer les données, comme une b ase de

données?
Si l'impératif est d'obtenir de grandes performances (ce qui

justifierai le partage mémoire entre processus ou threads), je ne
pense pas que la base de données soit adpatées.


C'est le cas.
Sinon, ce serait rigolo les jours de facture aux entrée et aux sorties
(sgbd assez chargé ...)


Est-ce que t'as regardé quelque chose un peu plus high-level que la
memoire partagé, par exemple BerkeleyDB?

http://www.oracle.com/database/docs/Berkeley-DB-v-Relational.pdfhttp://se arch.cpan.org/~pmqs/BerkeleyDB-0.31/BerkeleyDB.pod

Normalement c'est performant et peut gèrer le locking etc soi-même.

Marl


Salut,

dans le cadre de mon projet, j'utilise également DB Berkeley, mais a
un usage non volatile, cad permettant de retrouver les infos après
coupure ou redémarrage du serveur.

C'est un système performant, mais basé sur des fichiers, je doute que
cette technologie soit plus performante que de la mémoire pure ...

Je n'ai malheureusement pas le temps de vérifier.





Sébastien Cottalorda
Le #146673
On 17 juin, 15:30, Jérémy JUST
Le Fri, 15 Jun 2007 09:45:07 -0000,

Utilise un système adapté pour gérer les données, comme une b ase
de données?
Si l'impératif est d'obtenir de grandes performances (ce qui

justifierai le partage mémoire entre processus ou threads), je ne
pense pas que la base de données soit adpatées.
C'est le cas.

Sinon, ce serait rigolo les jours de facture aux entrée et aux sorties
(sgbd assez chargé ...)


Pour mon information, tu as fait des tests avec un SGBD genre
Postgresql? C'est réellement moins performant que ton système?

Parce que dans mon expérience (table avec deux à trois millions
d'enregistrements), la différence n'est pas si franche. J'ai comparé
deux systèmes:
- un hash maintenu en mémoire par un démon en Perl, à qui on adres sait
des requêtes par un socket (client en Perl),
- une bête table sous Postgresql, indexée.

Pour une requête sur la clef du hash, le démon en Perl était plus
rapide d'un facteur 2 à 3.


Je suis *très majoritairement* dans ce cas de figure.

Pour des requêtes ne portant plus sur la
clef du hash, il fallait créer un second hash à côté, ce qui doub lait
presque la RAM utilisée et donnait des performances proches de celles
Postgresql.
La différence principale était au moment du remplissage des
structures: il suffisait de quelques minutes pour remplir le hash avec
les 3 millions d'enregistrements, à partir d'un fichier tabulé, tandis
qu'il fallait une à deux heures pour Postgresql.

Voyant ces chiffres, j'ai du mal à imaginer que des entrées/sorties de
parkings puissent saturer l'un ou l'autre des systèmes.


Tu serais surpris de tout ce qui se passe lorsque tu entres ta carte
de parking .....
C'est un système temps réel beaucoup plus compliqué que tu ne peux
l'imaginer.

Par contre,
utiliser un SGBD te soulagerait de bien des soucis pour les
verrouillages et le partage entre processus.



Je ne suis pas d'accord, même pour une SGBD tu as a gérer des locks
exclusifs ou non.
Mon problème n'est pas réglé pour autant.

Tu ne fais que reporter le problème sur la SGBD, mais comment crois-tu
qu'elle gère les lock de tables ?



--
Jérémy JUST




Publicité
Poster une réponse
Anonyme