Bonsoir.
Y a t-il un moyen de savoir si un objet est référencé, ou bien connaître
le nombre de pointeurs sur l'objet en question ?
Pour expliqué, j'ai une classe faisant office de Cache, un thread est
lancé pour supprimer périodiquement les objets expirés.
Problème d'entrelacement si je récupère un objet, il n'est pas 'null', le
thread l'efface juste après ce teste et je le manipule par la suite...
Je ne souhaite pas utiliser .Clone(), et puis les objets du Cache
n'implémentent pas forcément IClonable.
Bonsoir.
Y a t-il un moyen de savoir si un objet est référencé, ou bien connaître
le nombre de pointeurs sur l'objet en question ?
Pour expliqué, j'ai une classe faisant office de Cache, un thread est
lancé pour supprimer périodiquement les objets expirés.
Problème d'entrelacement si je récupère un objet, il n'est pas 'null', le
thread l'efface juste après ce teste et je le manipule par la suite...
Je ne souhaite pas utiliser .Clone(), et puis les objets du Cache
n'implémentent pas forcément IClonable.
Bonsoir.
Y a t-il un moyen de savoir si un objet est référencé, ou bien connaître
le nombre de pointeurs sur l'objet en question ?
Pour expliqué, j'ai une classe faisant office de Cache, un thread est
lancé pour supprimer périodiquement les objets expirés.
Problème d'entrelacement si je récupère un objet, il n'est pas 'null', le
thread l'efface juste après ce teste et je le manipule par la suite...
Je ne souhaite pas utiliser .Clone(), et puis les objets du Cache
n'implémentent pas forcément IClonable.
[...]
[...]
[...]
Dans son message précédent, Delf a écrit :[...]
Bizarre, je vois des posts sous Google Group mais non pas via Free...
Lorsque mon thread traite chaque élément du Cache, il regarde si l'item
implémente IDisposable, si oui, il invoque la méthode Dispose().
Finalement, il Remove() l'item de la collection. Le tout, en section
critique.
Mon problème est dû à un entrelacement particulier.
1. Côté code, je récupère un pointeur sur mon item du Cache :
object o = CacheManager.Get("monObjet");
if (o != null)
{
// entrelacement à ce niveau-là...
L'objet n'est pas expiré, o est donc différent de 'null'.
2. Un instant après, le thread "purgatoire" se réveille, analyse l'item
"monObjet" ; à ce moment là, il peut être expiré : il est effacé de la
collection.
3. Côté code, je fais
// dans le if précédent...
Console.WriteLine(o.ToString());
}
L'item n'existant plus, o vaut null, NullReferenceException...
Ce que je voudrais faire : lorsque le thread parcourt la collection, pour
chaque item, savoir s'il est référencé ailleurs.
Genre : if (o != null && o.ReferenceNumber != 0) ...
Une personne parlait d'utiliser un SerializerSugotruc (je ne connais pas).
J'ai trouvé sur le MSDN une source d'exemple que j'ai testée. J'ai
notamment relevé une propriété sur le stream : Position qui change quand
le stream est lu.
Je pourrais surement m'en servir pour savoir si l'objet a 'été référencé'
avant que le thread ne soit lancé (repositionné par le thread à 0 à la
première boucle ; à la seconde, si valeur = 0 alors on peut effacer)
Mais ça me paraît lourd comme méthode...
Dans son message précédent, Delf a écrit :
[...]
Bizarre, je vois des posts sous Google Group mais non pas via Free...
Lorsque mon thread traite chaque élément du Cache, il regarde si l'item
implémente IDisposable, si oui, il invoque la méthode Dispose().
Finalement, il Remove() l'item de la collection. Le tout, en section
critique.
Mon problème est dû à un entrelacement particulier.
1. Côté code, je récupère un pointeur sur mon item du Cache :
object o = CacheManager.Get("monObjet");
if (o != null)
{
// entrelacement à ce niveau-là...
L'objet n'est pas expiré, o est donc différent de 'null'.
2. Un instant après, le thread "purgatoire" se réveille, analyse l'item
"monObjet" ; à ce moment là, il peut être expiré : il est effacé de la
collection.
3. Côté code, je fais
// dans le if précédent...
Console.WriteLine(o.ToString());
}
L'item n'existant plus, o vaut null, NullReferenceException...
Ce que je voudrais faire : lorsque le thread parcourt la collection, pour
chaque item, savoir s'il est référencé ailleurs.
Genre : if (o != null && o.ReferenceNumber != 0) ...
Une personne parlait d'utiliser un SerializerSugotruc (je ne connais pas).
J'ai trouvé sur le MSDN une source d'exemple que j'ai testée. J'ai
notamment relevé une propriété sur le stream : Position qui change quand
le stream est lu.
Je pourrais surement m'en servir pour savoir si l'objet a 'été référencé'
avant que le thread ne soit lancé (repositionné par le thread à 0 à la
première boucle ; à la seconde, si valeur = 0 alors on peut effacer)
Mais ça me paraît lourd comme méthode...
Dans son message précédent, Delf a écrit :[...]
Bizarre, je vois des posts sous Google Group mais non pas via Free...
Lorsque mon thread traite chaque élément du Cache, il regarde si l'item
implémente IDisposable, si oui, il invoque la méthode Dispose().
Finalement, il Remove() l'item de la collection. Le tout, en section
critique.
Mon problème est dû à un entrelacement particulier.
1. Côté code, je récupère un pointeur sur mon item du Cache :
object o = CacheManager.Get("monObjet");
if (o != null)
{
// entrelacement à ce niveau-là...
L'objet n'est pas expiré, o est donc différent de 'null'.
2. Un instant après, le thread "purgatoire" se réveille, analyse l'item
"monObjet" ; à ce moment là, il peut être expiré : il est effacé de la
collection.
3. Côté code, je fais
// dans le if précédent...
Console.WriteLine(o.ToString());
}
L'item n'existant plus, o vaut null, NullReferenceException...
Ce que je voudrais faire : lorsque le thread parcourt la collection, pour
chaque item, savoir s'il est référencé ailleurs.
Genre : if (o != null && o.ReferenceNumber != 0) ...
Une personne parlait d'utiliser un SerializerSugotruc (je ne connais pas).
J'ai trouvé sur le MSDN une source d'exemple que j'ai testée. J'ai
notamment relevé une propriété sur le stream : Position qui change quand
le stream est lu.
Je pourrais surement m'en servir pour savoir si l'objet a 'été référencé'
avant que le thread ne soit lancé (repositionné par le thread à 0 à la
première boucle ; à la seconde, si valeur = 0 alors on peut effacer)
Mais ça me paraît lourd comme méthode...
Je suppose que le problême exposé par notre ami est un exercice donné
dans le cadre de ses études, ai je tort?
je pense qu'il faut d'abord rappeler quelques point:
Le Garbage Collector:
Lorsqu'il y a besoin de libérer de la mémoire le garbage collector
de .Net recherche les objets orphelins en mémoire, c'est à dire non
référencé (je vais à l'essentiel et vous fait grâce de la notion de
génération dans mes explications).
Comment détecte t'il qu'un objet est orphelin?
Les variables et propriétés référençant des objets définis par des
classes sont en fait des "références". Le Garbage Collector recense
donc tous les objets en mémoire qui ne sont pas la cible de ces
références et les désigne comme orphelins.
L'interface IDispose:
Cette interface à pour rôle de mettre à disposition un mécanisme de
libération des ressources, typiquement handles de fichier, connections
à une base de données...
Le résultat de IDispose n'est en aucun cas la libération de la
mémoire occupée par l'objet lui même pour lequel on appelle IDispose.
Si on garde une référence sur un objet sur lequel on a utilisé
IDispose, le garbage collector ne le recyclera pas.
Les objets Streams:
les objets streams sont des objets d'accés "séquentiel" à des
données. La propriété "Position"désigne l'emplacement dans le stream
où l'on va lire ou écrire de l'information, aucunement un compteur de
référencement.
Concernant le système de cache expliqué ici, il ne libérera pas la
mémoire des objets (je ne parle pas ici des sous-objets dont les
références pourraient être supprimées par la méthode Dispose)
référencés par le cache, sauf à certaines conditions:
1 * l'objet n'est pas référencé à l'extérieur du cache
2 * lorsque l'on veut supprimer l'objet on met sa référence à null
3 * on appelle le garbage collector (ce qui est généralement
déconseillé, il vaut mieux laisser le framework l'activer lui même
quand il le juge nécessaire)
4 * le garbage collector trouve utile de recycler l'objet
C'est donc trés aléatoire, qui plus est dangereux, car si un objet est
utilisé et que la méthode Dispose libère des ressources essentielles
au bon fonctionnement de cet objet...
Mais je connais une solution ,dont je serais heureux de discuter avec
toi si tu poses les bonnes questions...
Pour donner une piste utile je conseillerais de lire l'article
suivant:
http://msdn.microsoft.com/en-us/library/system.weakreference.aspx
(jIl y a un système de cache en exemple ;) )
Si tu peux mettre la mains sur le livre "Applied .Net Framework
Programming" de Jeffrey Richter, tu pourras aussi apprendre des choses
utiles.
Je suppose que le problême exposé par notre ami est un exercice donné
dans le cadre de ses études, ai je tort?
je pense qu'il faut d'abord rappeler quelques point:
Le Garbage Collector:
Lorsqu'il y a besoin de libérer de la mémoire le garbage collector
de .Net recherche les objets orphelins en mémoire, c'est à dire non
référencé (je vais à l'essentiel et vous fait grâce de la notion de
génération dans mes explications).
Comment détecte t'il qu'un objet est orphelin?
Les variables et propriétés référençant des objets définis par des
classes sont en fait des "références". Le Garbage Collector recense
donc tous les objets en mémoire qui ne sont pas la cible de ces
références et les désigne comme orphelins.
L'interface IDispose:
Cette interface à pour rôle de mettre à disposition un mécanisme de
libération des ressources, typiquement handles de fichier, connections
à une base de données...
Le résultat de IDispose n'est en aucun cas la libération de la
mémoire occupée par l'objet lui même pour lequel on appelle IDispose.
Si on garde une référence sur un objet sur lequel on a utilisé
IDispose, le garbage collector ne le recyclera pas.
Les objets Streams:
les objets streams sont des objets d'accés "séquentiel" à des
données. La propriété "Position"désigne l'emplacement dans le stream
où l'on va lire ou écrire de l'information, aucunement un compteur de
référencement.
Concernant le système de cache expliqué ici, il ne libérera pas la
mémoire des objets (je ne parle pas ici des sous-objets dont les
références pourraient être supprimées par la méthode Dispose)
référencés par le cache, sauf à certaines conditions:
1 * l'objet n'est pas référencé à l'extérieur du cache
2 * lorsque l'on veut supprimer l'objet on met sa référence à null
3 * on appelle le garbage collector (ce qui est généralement
déconseillé, il vaut mieux laisser le framework l'activer lui même
quand il le juge nécessaire)
4 * le garbage collector trouve utile de recycler l'objet
C'est donc trés aléatoire, qui plus est dangereux, car si un objet est
utilisé et que la méthode Dispose libère des ressources essentielles
au bon fonctionnement de cet objet...
Mais je connais une solution ,dont je serais heureux de discuter avec
toi si tu poses les bonnes questions...
Pour donner une piste utile je conseillerais de lire l'article
suivant:
http://msdn.microsoft.com/en-us/library/system.weakreference.aspx
(jIl y a un système de cache en exemple ;) )
Si tu peux mettre la mains sur le livre "Applied .Net Framework
Programming" de Jeffrey Richter, tu pourras aussi apprendre des choses
utiles.
Je suppose que le problême exposé par notre ami est un exercice donné
dans le cadre de ses études, ai je tort?
je pense qu'il faut d'abord rappeler quelques point:
Le Garbage Collector:
Lorsqu'il y a besoin de libérer de la mémoire le garbage collector
de .Net recherche les objets orphelins en mémoire, c'est à dire non
référencé (je vais à l'essentiel et vous fait grâce de la notion de
génération dans mes explications).
Comment détecte t'il qu'un objet est orphelin?
Les variables et propriétés référençant des objets définis par des
classes sont en fait des "références". Le Garbage Collector recense
donc tous les objets en mémoire qui ne sont pas la cible de ces
références et les désigne comme orphelins.
L'interface IDispose:
Cette interface à pour rôle de mettre à disposition un mécanisme de
libération des ressources, typiquement handles de fichier, connections
à une base de données...
Le résultat de IDispose n'est en aucun cas la libération de la
mémoire occupée par l'objet lui même pour lequel on appelle IDispose.
Si on garde une référence sur un objet sur lequel on a utilisé
IDispose, le garbage collector ne le recyclera pas.
Les objets Streams:
les objets streams sont des objets d'accés "séquentiel" à des
données. La propriété "Position"désigne l'emplacement dans le stream
où l'on va lire ou écrire de l'information, aucunement un compteur de
référencement.
Concernant le système de cache expliqué ici, il ne libérera pas la
mémoire des objets (je ne parle pas ici des sous-objets dont les
références pourraient être supprimées par la méthode Dispose)
référencés par le cache, sauf à certaines conditions:
1 * l'objet n'est pas référencé à l'extérieur du cache
2 * lorsque l'on veut supprimer l'objet on met sa référence à null
3 * on appelle le garbage collector (ce qui est généralement
déconseillé, il vaut mieux laisser le framework l'activer lui même
quand il le juge nécessaire)
4 * le garbage collector trouve utile de recycler l'objet
C'est donc trés aléatoire, qui plus est dangereux, car si un objet est
utilisé et que la méthode Dispose libère des ressources essentielles
au bon fonctionnement de cet objet...
Mais je connais une solution ,dont je serais heureux de discuter avec
toi si tu poses les bonnes questions...
Pour donner une piste utile je conseillerais de lire l'article
suivant:
http://msdn.microsoft.com/en-us/library/system.weakreference.aspx
(jIl y a un système de cache en exemple ;) )
Si tu peux mettre la mains sur le livre "Applied .Net Framework
Programming" de Jeffrey Richter, tu pourras aussi apprendre des choses
utiles.
Si je comprends bien maintenant, le problême viens du fait que l'objet
peut être passé à "NULL" alors qu'il est à disposition à l'extérieur
du cache?
Les objets mis à dispositions par ce cache peuvent ils être de tous
types, ou juste d'un certain nombre restreint de types, voir un seul?
Si je comprends bien maintenant, le problême viens du fait que l'objet
peut être passé à "NULL" alors qu'il est à disposition à l'extérieur
du cache?
Les objets mis à dispositions par ce cache peuvent ils être de tous
types, ou juste d'un certain nombre restreint de types, voir un seul?
Si je comprends bien maintenant, le problême viens du fait que l'objet
peut être passé à "NULL" alors qu'il est à disposition à l'extérieur
du cache?
Les objets mis à dispositions par ce cache peuvent ils être de tous
types, ou juste d'un certain nombre restreint de types, voir un seul?
Arnaud Lhopiteau a exprimé avec précision :Les objets mis à dispositions par ce cache peuvent ils être de tous
types, ou juste d'un certain nombre restreint de types, voir un seul?
Pour l'instant je n'ai mis aucune limitation de type.
Est-ce une erreur ?
Arnaud Lhopiteau a exprimé avec précision :
Les objets mis à dispositions par ce cache peuvent ils être de tous
types, ou juste d'un certain nombre restreint de types, voir un seul?
Pour l'instant je n'ai mis aucune limitation de type.
Est-ce une erreur ?
Arnaud Lhopiteau a exprimé avec précision :Les objets mis à dispositions par ce cache peuvent ils être de tous
types, ou juste d'un certain nombre restreint de types, voir un seul?
Pour l'instant je n'ai mis aucune limitation de type.
Est-ce une erreur ?
Arnaud Lhopiteau a exprimé avec précision :
> Si je comprends bien maintenant, le problême viens du fait que l'obje t
> peut être passé à "NULL" alors qu'il est à disposition à l'ex térieur
> du cache?
Oui.
> Les objets mis à dispositions par ce cache peuvent ils être de tous
> types, ou juste d'un certain nombre restreint de types, voir un seul?
Pour l'instant je n'ai mis aucune limitation de type.
Est-ce une erreur ?
--
Delf
Arnaud Lhopiteau a exprimé avec précision :
> Si je comprends bien maintenant, le problême viens du fait que l'obje t
> peut être passé à "NULL" alors qu'il est à disposition à l'ex térieur
> du cache?
Oui.
> Les objets mis à dispositions par ce cache peuvent ils être de tous
> types, ou juste d'un certain nombre restreint de types, voir un seul?
Pour l'instant je n'ai mis aucune limitation de type.
Est-ce une erreur ?
--
Delf
Arnaud Lhopiteau a exprimé avec précision :
> Si je comprends bien maintenant, le problême viens du fait que l'obje t
> peut être passé à "NULL" alors qu'il est à disposition à l'ex térieur
> du cache?
Oui.
> Les objets mis à dispositions par ce cache peuvent ils être de tous
> types, ou juste d'un certain nombre restreint de types, voir un seul?
Pour l'instant je n'ai mis aucune limitation de type.
Est-ce une erreur ?
--
Delf