2009-01-22 7 views
0

Mon application fonctionne sur un système d'exploitation pSOS. Le code est compilé avec le compilateur Diab C.Modification du type de variable 32 bits en variable 64 bits?

l'application définit un certain nombre de compteurs qui ont été déclarés comme

unsigned int call_count; 

Comme il y a des chances de certains d'entre eux débordent dans un petit laps de temps, j'ai décidé de déclarer les compteurs comme

unsigned long long int call_count; 

Je crois que cela ne déborderait pas au moins de ma vie.

Ma question est cette conversion sans danger? Y a-t-il des frais généraux dont j'ai besoin? Lorsque l'application est soumise à un stress, le call_count est incrémenté sans cesse. La performance peut-elle prendre un coup? Un gestionnaire SNMP interroge également ces compteurs toutes les 15 secondes.

+0

Si vous venez utiliser ordinaire long, vous pouvez faire 1000 par seconde pour les prochains milliards d'années sans déborder. –

+0

S'il utilise ordinaire long, il ferait 1000 par seconde pendant 47 jours sans débordement. C'est ce que Windows 98 a fait. – Quassnoi

+0

@Paul: Le gestionnaire SNMP utilise counter64. Par conséquent, je dois le déclarer comme «long long» –

Répondre

2

Votre code suppose-t-il que l'incrémentation d'une variable 32 bits est une opération atomique? L'incrémentation d'une variable 64 bits sur un processeur 32 bits ne sera probablement pas atomique, à moins que vous ne fassiez tout votre possible pour le faire.

Exemple:.

  1. call_count égal 0x00000005FFFFFFFF lorsqu'un appel arrive
  2. La moitié inférieure de call_count est incrémenté: call_count se prépare à 0x000000500000000 et se prépare à 1.
  3. le bit de report de la CPU La moitié supérieure de call_count est incrémentée par le bit de retenue: call_count est défini sur 0x0000000600000000.

Si un autre thread ou un gestionnaire d'interruption lit la valeur de call_count entre les étapes 2 et 3, il obtiendra le mauvais résultat (0x000000500000000 au lieu de 0x000000600000000). La solution consiste à synchroniser l'accès à call_count.Quelques possibilités:

  • désactiver les interruptions (le cas échéant)
  • accès sérialisation à l'aide d'un verrou
  • Lire et écrire en utilisant des fonctions atomiques/interverrouillage (exemple: InterlockedIncrement() sous Windows)
1

Je doute qu'il y ait un problème de performance, au moins si vous utilisez un processeur 64 bits, puisque la variable est presque toujours dans le cache.

1

Dans de larges limites, le changement est inoffensif. Vous devrez vous assurer que tout code accédant à la valeur est prêt à traiter une quantité de 64 bits, et tout code qui formate sa valeur devra être changé, mais sinon, il devrait être suffisamment sûr - en l'absence de tout des informations sur d'autres codes qui seraient brisés par le changement.

0

Cela devrait aller. Je suppose (du pSOS) que vous êtes en train de coder un Moto 68000, qui est un processeur 32-bit; travailler avec des nombres de 64 bits est légèrement plus lent parce qu'il a besoin de quelques instructions supplémentaires (par exemple, ajouter, vérifier, transporter ou ajouter à un mot élevé) mais je doute que vous vous inquiétiez beaucoup d'un coût de quatre cycles. Si vous utilisez un processeur 64 bits, les opérations 64 bits sont exactement aussi rapides que les opérations 32 bits. Cela augmentera naturellement le temps de stockage de votre mémoire, mais encore une fois cela ne vous préoccupe que si vous avez un grand nombre de structures contenant ces compteurs.

Questions connexes