comme Je veux m'assurer que lorsque le "thread de suppression" entre dans la collection, tous les articles ont leur dernier "dernier accès" DateTime à ce sujet, afin que je puisse éviter de créer à nouveau l'élément simplement parce qu'un cache détenu La valeur pour un couple de millisecondes: D p> Merci d'avance. P> p> DateTime code> ne peut pas être déclaré aussi volatile, est-ce correct ?: private DateTime _time;
public DateTime Time
{
get
{
Thread.MemoryBarrier();
return _time;
}
set
{
_time = value;
Thread.MemoryBarrier();
}
}
3 Réponses :
Ce n'est pas possible - vous devrez utiliser Ceci est parce que de msdn - Volatile (référence C #) :
Le mot clé volatile peut être appliqué aux champs de ces types:
Comme d'autres personnes ont mentionné, vous pouvez utiliser verrouillage ou la classe pour synchroniser l'accès au champ.
DateTime est un type de valeur - une solide.
cochs pour suivre l'heure.
précisément.
Mais, vous avez une autre option. Stockez l'heure en tant que comptoir de tiques INT64 et utilisez EDIT: Étant donné que vous avez fourni plus d'informations, il est plus facile de fournir un exemple. < Pré> xxx interlockedexchange à définir. Les threads peuvent ensuite construire leur propre DateTime à l'aide du int64 constructeur, ne vous donnant aucune conflit et aucun verrouillage.
Mieux vaut utiliser Tobiny / fromarary plutôt que de stocker simplement les tiques brutes, de sorte que le DateTimeKind soit préservé. (Bien que je dirais que l'OP devrait probablement simplement utiliser un verrouillage et une date de date plutôt que d'essayer d'être trop intelligent.)
Bien que possible, ces deux suggestions sonnent que de nombreuses conversions redondantes impliquées. Cela dépend bien sûr du nombre de consommateurs que la valeur DateTime a.
@ Sensai76, peut-être, mais je doute que la conversion soit une surcharge gênante (bien qu'il soit difficile de dire sans savoir comment cela est utilisé par les autres threads), et cela dit, il sera moins aérien que par une sorte de serrure .
Vous définissez la valeur atomiquement, mais rien ne garantit que la propriété touchée lisez itomiquement.
Je pense qu'il manquera un nouveau mot-clé devant DateTime (verrouillé.Read (réf / Touched));
Votre code n'est pas le thread-coffre-fort car l'attribution de Vous pouvez probablement utiliser Mais si vous passez à des ticks, vous devez savoir que seuls 62 bits sont utilisés pour les tiques et 2 bits pour le type. Donc, vous ne perdez pas le genre.
Et même si vous faites le getter and Setter atomique un threadsafe, je ne suis pas sûr que cela suffit. Depuis que le temps peut changer entre le moment où votre getter retourne et le temps que vous travaillez réellement avec le temps que vous avez obtenu. Donc, votre temps peut toujours être obsolète. DateTime n'est pas garantie d'être atomique. En règle générale d'entiers d'entiers allant jusqu'à 32bits sont atomiques, mais 64 ne doivent pas être atomiques.
interlocked.exchange avec les ticks du DateTime car cela peut stocker atomiquement un intT64.
Ceci est une application X64 pour les machines X64. Est-ce que ça importe? Bon point.
@vtortola Selon ceci, des affectations 64 bits peuvent être atomiques: la CLI garantit qui lit et écrit des variables de types de valeur qui sont la taille (ou la plus petite) de la taille du pointeur naturel du processeur sont atomiques; Si vous exécutez C # Code sur un système d'exploitation 64 bits dans une version 64 bits du CLR, on lit et écrit de 64 bits doubles et de longs entiers sont également garantis en atomique. La langue C # ne garantit pas que, mais la spécification de l'exécution fait. Stackoverflow.com/a/11745471/67824
Je ne sais pas si ce que vous essayez de faire a du sens. Comment définissez-vous la dernière version?
Étant donné que vous implémentez un cache qui élimine les objets non utilisés plus anciens qu'une période de temps particulière, je pense que la solution
InterlockedExchange est le moyen d'aller ici.Vous savez que DateTime.NOW n'est que précis à 1/64 de seconde, non? Si vous êtes inquiet de l'inexactitude due aux caches retardant les millisecondes, vous avez déjà perdu; La précision des données que vous essayez de rester précis est de loin, bien inférieure à 1/1000 d'une seconde à tout moment.
@Eric, question: le datetime.now ne pas 't énumérer un 1/64 d'une seconde. Où est-ce documenté?
@ yodaj007: ça fait aussi. Il est indiqué que sur les systèmes d'exploitation NT3.5 et une plus grande précision est d'environ 10 millisecondes, soit 1 / 100ème d'une seconde. "Environ" signifie "pas exactement"; Le système d'exploitation est autorisé à décider de la précision appropriée. C'est généralement proche du fil quantique, pour des raisons évidentes. Sur ma machine, il est précis à 1 / 64ème d'une seconde; votre machine pourrait être meilleure ou pire.
@Eric: gotcha. Je calculais 1/64 = 0,015 seconde, ou 15.6ms. Mais je n'ai pas vu le mot "approximatif". Merci.