As you alluded to, await is thin enough that it doesn’t see threads in the first place. The code associated with await (the compiler-generated code within the state machine, and the support classes in the BCL) will only ever run on one thread at a time. (it can switch to a different thread when coming … Read more
Absolutely not; here’s a simple example lifted from 4.0 via reflector: [SecuritySafeCritical] public StringBuilder Append(char value) { if (this.m_ChunkLength < this.m_ChunkChars.Length) { this.m_ChunkChars[this.m_ChunkLength++] = value; } else { this.Append(value, 1); } return this; } The attribute just handles callers, not thread-safety; this is absolutely not thread-safe. Update: looking at the source he references, this is … Read more
In the Intel® 64 and IA-32 Architectures Developer’s Manual: Vol. 3A, which nowadays contains the specifications of the memory ordering white paper you mention, it is said in section 8.1.1 that: The Intel486 processor (and newer processors since) guarantees that the following basic memory operations will always be carried out atomically: Reading or writing a … Read more
It is not related to inheritance. It is an informal expression and means more like “some functions are thread-safe by their nature”. For example a function which does not touch any shared values/state is thread safe anyway i.e. “is inherently thread-safe”.
What makes an object not thread safe? An object is not thread safe if the value/state of that object can change while a thread is reading it. This generally happens if a second thread changes this object’s value while the first thread is reading it. An immutable object, by definition, cannot change value/state. Since every … Read more
[WRONG: Please see answers below] No, it is not thread-safe by default. You shoud use locking-related SQLiteHelper methods to provide thread safety. [EDIT]: SQLiteDatabase class provides a locking mechanism by default (see comments) and if you are running on multithread, you don’t have to consider changing anything to have thread-safety. Search for ‘thread’ in this … Read more
Why use Runnable over Thread? Runnable separates code that needs to run asynchronously, from how the code is run. This keeps your code flexible. For instance, asynchronous code in a runnable can run on a threadpool, or a dedicated thread. A Thread has state your runnable probably doesn’t need access to. Having access to more … Read more
I’m running into a similar issue, as far as I can tell you have to deal with the error handling yourself. My solution is to update the UI via a method call: Something like: try { //blah… } catch (Exception e) { reportAndLogException(e); } … public void reportAndLogException(final Throwable t) { Platform.runLater(new Runnable() { @Override … Read more
Yes, you are right, the user delegates are not synchronized by ConcurrentDictionary. If you need those synchronized it is your responsibility. The MSDN itself says: Also, although all methods of ConcurrentDictionary are thread-safe, not all methods are atomic, specifically GetOrAdd and AddOrUpdate. The user delegate that is passed to these methods is invoked outside of … Read more
Yes, the MemoryCache class is thread safe: System.Runtime.Caching.MemoryCache is threadsafe. Multiple concurrent threads can read and write a MemoryCache instance. Internally thread-safety is automatically handled to ensure the cache is updated in a consistent manner. What this might be referring to is that data stored within the cache may itself not be threadsafe. For example … Read more