c# - identificateur d´objet

c# - identificateur d´objet - C#/.NET managed - Programmation

Marsh Posté le 16-06-2004 à 16:00:27    

Voila jai un objet kkonque que je veux doter (sans mauvais jeux de mot)
d´un identifiant int id.
 
le probleme c que cette classe n´a acces a aucune autre instance
permanabte ou je pourrai stocké un compteur.
 
en effet je veux que le premier objet soit d´id 1,
le deuxieme d´id 2 ect....
 
donc en fait un compteur globale pour toutes les instanciations de la meme classe, mais stocké dans cette meme classe.
 
je sais pas si je suis clair ?
merci.

Reply

Marsh Posté le 16-06-2004 à 16:00:27   

Reply

Marsh Posté le 16-06-2004 à 16:02:31    

fais donc, avec un membre static

Reply

Marsh Posté le 16-06-2004 à 16:51:05    

Code :
  1. public class Compteur
  2. {
  3.   static uint id = 0;
  5.   static uint NewId
  6.   {
  7.     get
  8.     {
  9.       lock(typeof(Compteur))
  10.         {
  11.           return ++id;
  12.         }
  13.     }
  14.   }
  16.   readonly uint my_id;
  18.   public Compteur()
  19.   {
  20.     this.my_id = Compteur.NewId;
  21.   }


 
je ferais quelque chose de comme ça moi
 
évidemment si t'as pas besoin de synchronisation, tu peux virer le lock, voir même la propriété NewId


Message édité par Taz le 16-06-2004 à 16:51:59
Reply

Marsh Posté le 17-06-2004 à 10:04:56    

oui tres bien taz
 
en fait jai untegrer ca dans ma class, car jen ai besoin qune fois.
mais ta solution est tres propre sinon.
du coup je n´ai gardé que ca (pas de thread concurrents )
 

Code :
  1. public int id =0;
  4.  static private int _MessageNumber = 0;
  6.  static public int MessageNumber
  7.  {
  8.   get { return ++_MessageNumber; }
  9.  }


 
mais je garde ta classe compteur dans un coin :D

Reply

Marsh Posté le 04-08-2004 à 01:25:58    

Taz a écrit :

Code :
  1. public class Compteur
  2. {
  3.   static uint id = 0;
  5.   static uint NewId
  6.   {
  7.     get
  8.     {
  9.       lock(typeof(Compteur))
  10.         {
  11.           return ++id;
  12.         }
  13.     }
  14.   }
  16.   readonly uint my_id;
  18.   public Compteur()
  19.   {
  20.     this.my_id = Compteur.NewId;
  21.   }


 
je ferais quelque chose de comme ça moi
 
évidemment si t'as pas besoin de synchronisation, tu peux virer le lock, voir même la propriété NewId


 
 
Je prend le thread un peu en retard, mais il y a quelque chose de bien plus propre pour cela, à savoir le mot clé "volatile" qui permet une synchronisation implicite des accès à une variable :
 

Code :
  1. public class Compteur
  2. {
  3.   static volatile int id = 0;
  5.   static int NewId
  6.   {
  7.     get
  8.     {
  9.       return ++id;
  10.     }
  11.   }
  13.   readonly int my_id;
  15.   public Compteur()
  16.   {
  17.     this.my_id = Compteur.NewId;
  18.   }


 
C'est plus propre que d'utiliser un Monitor sur l'instance de System.Type retournée par typeof. D'ailleurs, tu utilise probablement un comportement implicite du framework, à savoir que l'instance qui t'es retournée par typeof est systématiquement la même. (On peut espérer que cela reste le cas :) )
 
D'autre part, utiliser le type uint, c'est très mauvais car ce n'est pas CLSCompliant. Maintenant, si tu ne fais pas de code destiné à être utilisé par d'autre langage comme le VB, ca ne change pas grand chose. Autre chose encore... le mélange francais/anglais, c'est une question de gout, mais c'est à mon sens particulièrement crade :)
 
--
Jay
{Epitech.}
http://www.labtech.epitech.net/blogs/jaylee

Reply

Marsh Posté le 04-08-2004 à 08:08:30    

le volatile c'est de la branlette, ça synchronise que dal

Reply

Marsh Posté le 04-08-2004 à 11:13:59    

Taz a écrit :

le volatile c'est de la branlette, ça synchronise que dal


 
J'adore tes réponses, elles sont toujours constructives...  
 
Tu peux préciser ?
 
--
Jay
{Epitech.}
http://www.labtech.epitech.net/blogs/jaylee

Reply

Marsh Posté le 04-08-2004 à 11:24:18    

portant la doc est claire à ce sujet.
http://msdn.microsoft.com/library/ [...] latile.asp

Reply

Marsh Posté le 04-08-2004 à 11:26:49    

ben volatile c'est se rattraper aux branches. lis le paragraphe de l'ecma, regarde l'il produit, comprends que c'est pas solide, que si tu fais plus d'une instruction, t'es foutu.

Reply

Marsh Posté le 04-08-2004 à 11:54:11    

Taz a écrit :

ben volatile c'est se rattraper aux branches. lis le paragraphe de l'ecma, regarde l'il produit, comprends que c'est pas solide, que si tu fais plus d'une instruction, t'es foutu.


 
De quelle "instruction" parles-tu ? IL ? assembleur natif ? C# ?
 
Au passage, l'ECMA est assez clair sur le sujet...
 
--  
Jay  
{Epitech.}  
http://www.labtech.epitech.net/blogs/jaylee

Reply

Marsh Posté le 04-08-2004 à 11:54:11   

Reply

Marsh Posté le 04-08-2004 à 11:59:29    

je parle d'IL, et l'ecma est clair oui, il dit pas que écriture+lecture est atomique.

Reply

Marsh Posté le 04-08-2004 à 12:18:33    

Taz a écrit :

je parle d'IL, et l'ecma est clair oui, il dit pas que écriture+lecture est atomique.


 
Oui, mais volatile (System.Runtime.CompilerServices.IsVolatile) est un marqueur pour le champ en lui même. L'aspect atomique est guaranti par le type en lui même (pas plus long qu'un mot natif et aligné) et la barrière mémoire est garantie par l'instruction volatile (Opcode.Volatile) en IL.
 
Mis à part cela, pour beaucoup, le choix entre lock ou volatile est une histoire de gout.
 
--  
Jay  
{Epitech.}  
http://www.labtech.epitech.net/blogs/jaylee

Reply

Marsh Posté le 04-08-2004 à 12:25:48    

oui ben justement, regarde la tronche du MSIL. avec return ++machin, tu as 2 barrières. si tu fais ++machin, retun machin, tu en as 3, etc

Reply

Marsh Posté le 04-08-2004 à 12:45:22    

Taz a écrit :

oui ben justement, regarde la tronche du MSIL. avec return ++machin, tu as 2 barrières. si tu fais ++machin, retun machin, tu en as 3, etc


 
La synchronisation sur un champ ne peut mener qu'à l'utilisation de barrières sur chaque accès, c'est son modèle de fonctionnement. (Même si selon les architectures, certaines barrières sont des noop, ce dont l'IL n'a que faire)
 
Comme je disait précédemment, c'est une histoire de gout. On pourrait continuer longtemps comme ca... :)
 
--  
Jay  
{Epitech.}  
http://www.labtech.epitech.net/blogs/jaylee

Reply

Marsh Posté le 04-08-2004 à 14:17:43    

non, c'est pas une histoire de goût. Avec un volatile on synchronise que dal. Tu vois toi même qu'entre le moment ou tu lis et le moment ou tu écris, tout peut arriver.
 
lecture.sync
opération
écriture.sync
 
ça a toujours était un problème, ça n'a jamais synchronisé quoique ce soit. Tu devrais revoir tout ça et comprendre que volatile s'emploie dans un contexte parallèle mais pas pour synchroniser quoi que ce soit.
 
Tu t'es jamais dit que si volatile suffisait, ils se seraient pas emmerder à faire les http://msdn.microsoft.com/library/ [...] Topic.asp.
 
 
alors si ton gout c'est un truc foireux, ne le partage pas avec les autres.
 
 
 
Conclusion: utiliser soit lock/Attribut soit System.Treading.Interlocked


Message édité par Taz le 04-08-2004 à 14:18:57
Reply

Marsh Posté le 04-08-2004 à 15:45:13    

Taz a écrit :

non, c'est pas une histoire de goût. Avec un volatile on synchronise que dal. Tu vois toi même qu'entre le moment ou tu lis et le moment ou tu écris, tout peut arriver.
 
lecture.sync
opération
écriture.sync
 
ça a toujours était un problème, ça n'a jamais synchronisé quoique ce soit. Tu devrais revoir tout ça et comprendre que volatile s'emploie dans un contexte parallèle mais pas pour synchroniser quoi que ce soit.
 
Tu t'es jamais dit que si volatile suffisait, ils se seraient pas emmerder à faire les http://msdn.microsoft.com/library/ [...] Topic.asp.


 
En effet, c'est une erreur de ma part, j'ai sur-estimé le fonctionnement de volatile. Dans le cas d'une pre-incrémentation, l'opération complete n'est pas atomique, mais uniquement la lecture et l'affectation.
 

Taz a écrit :


alors si ton gout c'est un truc foireux, ne le partage pas avec les autres.


 
Les remarques de ce genre, tu peux te les garder pour toi... La courtoisie ce n'est pas fait que pour les chiens. L'intelligence appelle à l'humilité, manifestement pas la connaissance.
 

Taz a écrit :


Conclusion: utiliser soit lock/Attribut soit System.Treading.Interlocked


En effet.
 
--  
Jay  
{Epitech.}  
http://www.labtech.epitech.net/blogs/jaylee

Reply

Marsh Posté le 04-08-2004 à 15:47:24    

je serais resté froid si après lecture de l'ECMA et analyse du MSIL (et compréhension du .volatile) tu n'avais persisté à affirmer le contraire.
 
Tu comprends bien, qu'une barrière, on l'appelle barrière, si c'était un mutex, on l'aurait appelée mutex :)

Reply

Marsh Posté le 04-08-2004 à 16:12:54    

Taz a écrit :

je serais resté froid si après lecture de l'ECMA et analyse du MSIL (et compréhension du .volatile) tu n'avais persisté à affirmer le contraire.
 
Tu comprends bien, qu'une barrière, on l'appelle barrière, si c'était un mutex, on l'aurait appelée mutex :)


 
Je connais très bien l'un et l'autre... C'est mon interprétation de volatile qui était incorrecte :)
 
Au passage, Opcode.Volatile et IsVolatile sont des noop sur une archi uni-processeur x86, le JIT les ignore; ce ne doit pas être le cas sur une archi multiprocesseurs x86.
 
--
Jay
{Epitech.}  
http://www.labtech.epitech.net/blogs/jaylee


Message édité par jaylee le 04-08-2004 à 16:14:15
Reply

Marsh Posté le 04-08-2004 à 16:45:26    

je sais pas s'il les ignore. s'il fait comme un compilateur C, il va recharger plutot que de faire avec le contenu du registre. en fait voir l'ecma c'est bien expliqué


Message édité par Taz le 04-08-2004 à 16:52:16
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed