2010-01-14 7 views
0

J'ai un objet file d'attente .NET. Le thread producteur effectue l'opération Enqueue, les données placées dans la file d'attente sont un tableau byte [], tandis que l'autre thread consommateur effectue l'opération Dequeue sur le même objet file d'attente. J'utilise des verrous pour gérer la simultanéité. Mon code semble fonctionner tout le temps, mais hier, des choses bizarres se sont produites. Les données que j'ai obtenues à partir d'un thread consommateur étaient différentes des données que j'ai produites: la longueur du tableau est incorrecte, le tableau est répété ... Cela est-il dû à la protection thread-safe défaillante? À mon avis, la concurrence ne ferait que causer des pertes de données.Que se passerait-il dans un objet file d'attente .NET non sécurisé?

Mon premier message ici, ours avec moi.

+2

Pouvez-vous nous dire quel mécanisme vous utilisez pour verrouiller? par exemple. avec un échantillon de code très court. –

+0

Les problèmes de simultanéité entraînent une corruption ou une incohérence des données. Cela peut être une perte de données, des données répétées, des données corrompues ou même une exception. Ce qui se passe dépend de votre implémentation. Sans voir un exemple de ce que vous faites, personne ne peut avoir une idée de ce qu'est votre problème. – shf301

+0

merci pour vos commentaires! J'utilise simplement moniteur pour faire le "verrou" obtenir { Monitor.Enter (mQueue); octet [] data = mQueue.Dequeue(); Monitor.Exit (mQueue); données de retour; } défini { Monitor.Enter (mQueue); mQueue.Enqueue (valeur); Monitor.Exit (mQueue); } Quel est le problème avec cela? – Sunf71

Répondre

0

C'est bien pire que la simple perte de données. La classe Queue peut réaffecter son tampon interne lorsque cela est nécessaire pour accueillir un nombre croissant d'éléments. Un mauvais verrouillage peut accéder au nouveau tampon avec les anciennes valeurs des indices de tête et de queue. Vous obtiendrez seulement une exception quand vous avez de la chance, plus probable est que vous obtenez simplement le mauvais élément.

+0

oui, semble raisonnable. Merci – Sunf71

0

Le thread de production ne doit pas conserver de référence au tableau et le modifier après sa mise en file d'attente. Toujours créer un nouveau tableau. (Je peux dire l'évidence, mais il est difficile de faire mieux sans plus d'informations)