J'ai une appli multi-thread et à partir des différents threads j'accede à la
meme base de données en lecture ou ecriture (donc il se peut que plusieurs
thread veulent ecrire en meme temps dans la base).
Quels methodes dois je mettre en place pour eviter les problemes ? Dans quel
cas utiliser un mutex ou monitor ou autres choses pour ce genre de
situations ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
François Cheippe
J'ai une appli multi-thread et à partir des différents threads j'accede à la
meme base de données en lecture ou ecriture (donc il se peut que plusieurs thread veulent ecrire en meme temps dans la base).
Quels methodes dois je mettre en place pour eviter les problemes ? Dans quel
cas utiliser un mutex ou monitor ou autres choses pour ce genre de situations ?
En général, c'est le SGBD (s'il est bien conçu) qui se charge de bloquer/bufferiser les accès concurrents à la base de données. Si plusieurs opérations (i.e. requêtes) doivent être effectuées d'une seule traite, on peut utiliser les transactions (qui présentent également l'avantage de pouvoir revenir proprement en arrière en cas de problème).
-- François Cheippe
J'ai une appli multi-thread et à partir des différents threads j'accede à
la
meme base de données en lecture ou ecriture (donc il se peut que plusieurs
thread veulent ecrire en meme temps dans la base).
Quels methodes dois je mettre en place pour eviter les problemes ? Dans
quel
cas utiliser un mutex ou monitor ou autres choses pour ce genre de
situations ?
En général, c'est le SGBD (s'il est bien conçu) qui se charge de
bloquer/bufferiser les accès concurrents à la base de données. Si plusieurs
opérations (i.e. requêtes) doivent être effectuées d'une seule traite, on
peut utiliser les transactions (qui présentent également l'avantage de
pouvoir revenir proprement en arrière en cas de problème).
J'ai une appli multi-thread et à partir des différents threads j'accede à la
meme base de données en lecture ou ecriture (donc il se peut que plusieurs thread veulent ecrire en meme temps dans la base).
Quels methodes dois je mettre en place pour eviter les problemes ? Dans quel
cas utiliser un mutex ou monitor ou autres choses pour ce genre de situations ?
En général, c'est le SGBD (s'il est bien conçu) qui se charge de bloquer/bufferiser les accès concurrents à la base de données. Si plusieurs opérations (i.e. requêtes) doivent être effectuées d'une seule traite, on peut utiliser les transactions (qui présentent également l'avantage de pouvoir revenir proprement en arrière en cas de problème).
-- François Cheippe
MacTotoche
wrote:
Donc dans quel cas utiliser des mutex ou moniteur ?..
Hello,
Typiquement et en bref, quand des Threads concurrents doivent accéder à des ressources (variables) partagées.
S'il y a uniquement des accès en lecture, tout va bien. S'il y a aussi des ecritures/modifs, alors il faut assurer la cohérence des états des ressources partagées.
Ces "sections critiques" du code doivent être exécutées en exclusion mutuelle : les parties de code concernées doivent être protégées par un semaphore ou, plus naturellement en java, s'exécuter sous le contrôle d'un "moniteur" (mot clé et structure de contrôle synchronized(...) ).
Publi princeps sur les moniteurs de Hoare utilisés en java : http://www.acm.org/classics/feb96/
Premiers pas sur le site de sun : http://java.sun.com/docs/books/tutorial/essential/threads/multithreaded.html
Modèles/Poblèmes de coopération interprocess courants : producteur/consommateur, écrivain/lecteurs, (dining philosophers)
Problèmes associés à considérer : interblocage (deadlock) et famine (starvation) des processes concurrents.
Un problème spécifique à l'implémentation java qui /peut/ favoriser la famine : http://www.cs.kent.ac.uk/projects/ofa/java-threads/0.html
Et plein de ressources tout-partout accessibles par google.
J'ai bon ?
-- Olivier This space for sale.
Oliv@Oliv.com wrote:
Donc dans quel cas utiliser des mutex ou moniteur ?..
Hello,
Typiquement et en bref, quand des Threads concurrents doivent accéder
à des ressources (variables) partagées.
S'il y a uniquement des accès en lecture, tout va bien.
S'il y a aussi des ecritures/modifs, alors il faut assurer la
cohérence des états des ressources partagées.
Ces "sections critiques" du code doivent être exécutées en exclusion
mutuelle : les parties de code concernées doivent être protégées par
un semaphore ou, plus naturellement en java, s'exécuter sous le
contrôle d'un "moniteur" (mot clé et structure de contrôle
synchronized(...) ).
Publi princeps sur les moniteurs de Hoare utilisés en java :
http://www.acm.org/classics/feb96/
Premiers pas sur le site de sun :
http://java.sun.com/docs/books/tutorial/essential/threads/multithreaded.html
Modèles/Poblèmes de coopération interprocess courants :
producteur/consommateur, écrivain/lecteurs, (dining philosophers)
Problèmes associés à considérer : interblocage (deadlock) et famine
(starvation) des processes concurrents.
Un problème spécifique à l'implémentation java qui /peut/ favoriser la
famine :
http://www.cs.kent.ac.uk/projects/ofa/java-threads/0.html
Et plein de ressources tout-partout accessibles par google.
Donc dans quel cas utiliser des mutex ou moniteur ?..
Hello,
Typiquement et en bref, quand des Threads concurrents doivent accéder à des ressources (variables) partagées.
S'il y a uniquement des accès en lecture, tout va bien. S'il y a aussi des ecritures/modifs, alors il faut assurer la cohérence des états des ressources partagées.
Ces "sections critiques" du code doivent être exécutées en exclusion mutuelle : les parties de code concernées doivent être protégées par un semaphore ou, plus naturellement en java, s'exécuter sous le contrôle d'un "moniteur" (mot clé et structure de contrôle synchronized(...) ).
Publi princeps sur les moniteurs de Hoare utilisés en java : http://www.acm.org/classics/feb96/
Premiers pas sur le site de sun : http://java.sun.com/docs/books/tutorial/essential/threads/multithreaded.html
Modèles/Poblèmes de coopération interprocess courants : producteur/consommateur, écrivain/lecteurs, (dining philosophers)
Problèmes associés à considérer : interblocage (deadlock) et famine (starvation) des processes concurrents.
Un problème spécifique à l'implémentation java qui /peut/ favoriser la famine : http://www.cs.kent.ac.uk/projects/ofa/java-threads/0.html
Et plein de ressources tout-partout accessibles par google.
J'ai bon ?
-- Olivier This space for sale.
"Christophe M." a écrit dans le message de news: 3f2a3aa0$
Dans le cas ou tu veux un accès non-concurent de plusieurs threads sur une même ressource.
Mais pas avec un SGBD, puisqu'il gère ça tout seul, un souci en moins pour le programmeur ;-)
Et si ce n'est pas vraiment un SGBD (par exemple ACCESS ?... )
"Christophe M." <mccricri@yahoo.com> a écrit dans le message de news:
3f2a3aa0$1_1@news.vo.lu...
Dans le cas ou tu veux un accès non-concurent de plusieurs threads sur
une même ressource.
Mais pas avec un SGBD, puisqu'il gère ça tout seul, un souci en moins
pour le programmeur ;-)
Et si ce n'est pas vraiment un SGBD (par exemple ACCESS ?... )
"Christophe M." a écrit dans le message de news: 3f2a3aa0$
Dans le cas ou tu veux un accès non-concurent de plusieurs threads sur une même ressource.
Mais pas avec un SGBD, puisqu'il gère ça tout seul, un souci en moins pour le programmeur ;-)
Et si ce n'est pas vraiment un SGBD (par exemple ACCESS ?... )
Christophe M.
Dans le cas ou tu veux un accès non-concurent de plusieurs threads sur une même ressource.
Mais pas avec un SGBD, puisqu'il gère ça tout seul, un souci en moins pour le programmeur ;-)
wrote:
En général, c'est le SGBD (s'il est bien conçu) qui se charge de bloquer/bufferiser les accès concurrents à la base de données. Si
plusieurs
opérations (i.e. requêtes) doivent être effectuées d'une seule traite, on peut utiliser les transactions (qui présentent également l'avantage de pouvoir revenir proprement en arrière en cas de problème).
Donc dans quel cas utiliser des mutex ou moniteur ?..
Dans le cas ou tu veux un accès non-concurent de plusieurs threads sur
une même ressource.
Mais pas avec un SGBD, puisqu'il gère ça tout seul, un souci en moins
pour le programmeur ;-)
Oliv@Oliv.com wrote:
En général, c'est le SGBD (s'il est bien conçu) qui se charge de
bloquer/bufferiser les accès concurrents à la base de données. Si
plusieurs
opérations (i.e. requêtes) doivent être effectuées d'une seule traite, on
peut utiliser les transactions (qui présentent également l'avantage de
pouvoir revenir proprement en arrière en cas de problème).
Donc dans quel cas utiliser des mutex ou moniteur ?..
Dans le cas ou tu veux un accès non-concurent de plusieurs threads sur une même ressource.
Mais pas avec un SGBD, puisqu'il gère ça tout seul, un souci en moins pour le programmeur ;-)
wrote:
En général, c'est le SGBD (s'il est bien conçu) qui se charge de bloquer/bufferiser les accès concurrents à la base de données. Si
plusieurs
opérations (i.e. requêtes) doivent être effectuées d'une seule traite, on peut utiliser les transactions (qui présentent également l'avantage de pouvoir revenir proprement en arrière en cas de problème).
Donc dans quel cas utiliser des mutex ou moniteur ?..
narberd
"Christophe M." a écrit dans le message news: 3f2a51b3$
Je résisterai au trol ;-) en disant simplement que Access gère lui aussi les multiutilisateurs sant problème, avec possibilité de transaction.
wrote:
"Christophe M." a écrit dans le message de news: 3f2a3aa0$
Dans le cas ou tu veux un accès non-concurent de plusieurs threads sur une même ressource.
Mais pas avec un SGBD, puisqu'il gère ça tout seul, un souci en moins pour le programmeur ;-)
Et si ce n'est pas vraiment un SGBD (par exemple ACCESS ?... )
Ce que j'ai compris, après bien des déboires :
Access peut gérer des accès concurrent venant de plusieurs PROCESSUS (ou EXE) sans trop de problèmes. Cependant, il ne sait pas gérer des accès concurrent depuis plusieurs THREADS d'un même PROCESSUS. Je pense que c'est tout simplement lié au fait que les accès à Access (j'aime cette phrase !!) se font par l'intermédiaire d'une DLL (1) (msjetxxx.dll ou quelque chose comme ça). Les données d'une requête doivent être globales dans l'espace mémoire de l'application et sans contrôle d'accès par des verrous...
Je résisterai au trol ;-) (Ctrl+C Ctrl+V) en redisant que c'est ce que j'ai compris et pas forcément approfondi. Toujours est-il qu'en me protégeant des accès multiples en utilisant singletons et synchronisation, je ne me retrouve plus avec données et fichiers (ou base) Access complètement éclatées.
Narberd.
(1) DLL ou ActiveX ou Ocx, ce sont TOUJOURS des DLL qui peuvent partager leur espace de mémoire avec celui de l'application principale.
"Christophe M." <mccricri@yahoo.com> a écrit dans le message news:
3f2a51b3$1_2@news.vo.lu...
Je résisterai au trol ;-) en disant simplement que Access gère lui aussi
les multiutilisateurs sant problème, avec possibilité de transaction.
Oliv@Oliv.com wrote:
"Christophe M." <mccricri@yahoo.com> a écrit dans le message de news:
3f2a3aa0$1_1@news.vo.lu...
Dans le cas ou tu veux un accès non-concurent de plusieurs threads sur
une même ressource.
Mais pas avec un SGBD, puisqu'il gère ça tout seul, un souci en moins
pour le programmeur ;-)
Et si ce n'est pas vraiment un SGBD (par exemple ACCESS ?... )
Ce que j'ai compris, après bien des déboires :
Access peut gérer des accès concurrent venant de plusieurs PROCESSUS (ou
EXE) sans trop de problèmes. Cependant, il ne sait pas gérer des accès
concurrent depuis plusieurs THREADS d'un même PROCESSUS. Je pense que c'est
tout simplement lié au fait que les accès à Access (j'aime cette phrase !!)
se font par l'intermédiaire d'une DLL (1) (msjetxxx.dll ou quelque chose
comme ça). Les données d'une requête doivent être globales dans l'espace
mémoire de l'application et sans contrôle d'accès par des verrous...
Je résisterai au trol ;-) (Ctrl+C Ctrl+V) en redisant que c'est ce que j'ai
compris et pas forcément approfondi. Toujours est-il qu'en me protégeant des
accès multiples en utilisant singletons et synchronisation, je ne me
retrouve plus avec données et fichiers (ou base) Access complètement
éclatées.
Narberd.
(1) DLL ou ActiveX ou Ocx, ce sont TOUJOURS des DLL qui peuvent partager
leur espace de mémoire avec celui de l'application principale.
"Christophe M." a écrit dans le message news: 3f2a51b3$
Je résisterai au trol ;-) en disant simplement que Access gère lui aussi les multiutilisateurs sant problème, avec possibilité de transaction.
wrote:
"Christophe M." a écrit dans le message de news: 3f2a3aa0$
Dans le cas ou tu veux un accès non-concurent de plusieurs threads sur une même ressource.
Mais pas avec un SGBD, puisqu'il gère ça tout seul, un souci en moins pour le programmeur ;-)
Et si ce n'est pas vraiment un SGBD (par exemple ACCESS ?... )
Ce que j'ai compris, après bien des déboires :
Access peut gérer des accès concurrent venant de plusieurs PROCESSUS (ou EXE) sans trop de problèmes. Cependant, il ne sait pas gérer des accès concurrent depuis plusieurs THREADS d'un même PROCESSUS. Je pense que c'est tout simplement lié au fait que les accès à Access (j'aime cette phrase !!) se font par l'intermédiaire d'une DLL (1) (msjetxxx.dll ou quelque chose comme ça). Les données d'une requête doivent être globales dans l'espace mémoire de l'application et sans contrôle d'accès par des verrous...
Je résisterai au trol ;-) (Ctrl+C Ctrl+V) en redisant que c'est ce que j'ai compris et pas forcément approfondi. Toujours est-il qu'en me protégeant des accès multiples en utilisant singletons et synchronisation, je ne me retrouve plus avec données et fichiers (ou base) Access complètement éclatées.
Narberd.
(1) DLL ou ActiveX ou Ocx, ce sont TOUJOURS des DLL qui peuvent partager leur espace de mémoire avec celui de l'application principale.
Christophe M.
Je résisterai au trol ;-) en disant simplement que Access gère lui aussi les multiutilisateurs sant problème, avec possibilité de transaction.
wrote:
"Christophe M." a écrit dans le message de news: 3f2a3aa0$
Dans le cas ou tu veux un accès non-concurent de plusieurs threads sur une même ressource.
Mais pas avec un SGBD, puisqu'il gère ça tout seul, un souci en moins pour le programmeur ;-)
Et si ce n'est pas vraiment un SGBD (par exemple ACCESS ?... )
Je résisterai au trol ;-) en disant simplement que Access gère lui aussi
les multiutilisateurs sant problème, avec possibilité de transaction.
Oliv@Oliv.com wrote:
"Christophe M." <mccricri@yahoo.com> a écrit dans le message de news:
3f2a3aa0$1_1@news.vo.lu...
Dans le cas ou tu veux un accès non-concurent de plusieurs threads sur
une même ressource.
Mais pas avec un SGBD, puisqu'il gère ça tout seul, un souci en moins
pour le programmeur ;-)
Et si ce n'est pas vraiment un SGBD (par exemple ACCESS ?... )
