Repository navigation
NRE #505
Description
Activity
Mhm could still be everywhere.
We could be brutal and open debugger?
On Jan 2, 2015 4:23 PM, "Vasily Kirichenko" notifications@github.com
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.Breakplease.
Cannot understand what here is null tho :(
Maybe it's caused by concurrent access to
pathPenaltiesdictionary (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%28v=vs.110%29.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
ConcurrentDictionaryis 3x slower thanDictionary.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 ;)
