Mhm could still be everywhere.
We could be brutal and open debugger?
On Jan 2, 2015 4:23 PM, "Vasily Kirichenko" [email protected]
wrote:

[image: image]
https://cloud.githubusercontent.com/assets/873919/5597033/7b5ad624-92ac-11e4-9ae2-105348f0ec76.png

—
Reply to this email directly or view it on GitHub
#505.

Do you want me to pu Debugger.Break into this line: https://github.com/fsprojects/Paket/blob/master/src/Paket/Program.fs#L213 ?

Wait a minute, I'll try to reproduce it under debugger. Seem to appear after paket version updated.

Cannot catch it :( Yes, add Debugger.Break please.

Cannot understand what here is null tho :(

Maybe it's caused by concurrent access to pathPenalties dictionary (if it's concurrent)?

It seems that 4 threads are invoking this code:

wow didn't know that Dictionary is not thread-safe.
http://msdn.microsoft.com/en-us/library/dd287191(v=vs.110).aspx seems to be the one I should use, right?

:) Absolutely!

WTF. Why isn't the thread-safe version the default?
Ok I changed it.

Most of the collections in the BCL aren't thread safe.

All concurrent collection are much slower, for example, here http://stackoverflow.com/questions/15252115/concurrentdictionary-performance-at-a-single-thread-misunderstanding ConcurrentDictionary is 3x slower than Dictionary.

Yep I understan that - so I think in special case one could switch to UnsafeButFasterDictionary ;-)

Do you think we can close this? Or do you still see this error

I don't see it anymore. If it returns, I reopen this issue.

Just beware that ConcurrentDictionary has no notion of strict serialisability as:

• there's no global time
• you may perform double work when adding to the cache
• you cannot be guaranteed to read-your-writes between threads

Also note that ConcurrentDictionary is likely faster for your use-case of a cache, since your reads will outnumber your writes.

So all is well?

Yes ;)