![]() NET also offers a TaskScheduler that ensures that only one Task executes at a time: ConcurrentExclusiveSchedulerPair. So for example, we can do this:Īnother technique for ensuring that code executes only on one thread at a time is to use a TaskScheduler with a policy to only execute one Task at once.NET’s TaskScheduler.Default will schedule work by adding it to the threadpool queue, which means it may run multiple tasks concurrently. It may not always be a good idea to hold a semaphore for a long period of time, but it can be powerful when you need it as it guarantees that no one else can enter the semaphore and observe your object’s state while it’s in the middle of an async operation. So you can, for example await on something while holding a semaphore. Another rather unique feature of using semaphores is you can hold them without holding a thread. Also, semaphores can be held across asynchronous awaits, which C# lock won’t allow you to do. Locks will synchronously block until they’re available, but a semaphore can be awaited on. NET, the SemaphoreSlim class offers a WaitAsync method you can await on to efficiently yield your thread if the semaphore is not immediately available. Your multi-threaded code can enter such a semaphore before accessing non-thread-safe code as a way to allow your multi-threaded code to safely call it. In C#, the lock statement is very similar to a semaphore created with a count of 1. If the code you are writing is or can be async, you have at least a couple other options. ![]() Locks can be very lightweight and are often the right choice when you don’t expect lock contention to occur frequently or last a long time. But otherwise it is unnecessary overhead to create such a thread, since the constraint isn’t that you use exactly one thread, but merely one thread at-a-time.Ī very common way to call into code that is not thread-safe is similar to how you may be doing your own thread-safe code: wrap it with an exclusive lock. This may be required when the non-thread-safe code is a native COM object that actually requires the exact same thread be used for every call. If the docs don’t discuss it, you should assume it is not thread-safe.Ī less common solution might be to create a dedicated thread for accessing non-thread-safe code. Any library’s documentation should discuss how thread-safe it is (or isn’t). These details are in MSDN documentation for each type and member. NET Framework, most types are not thread-safe on their instance members, but are thread-safe for static members. Even if you think you’re writing thread-safe code you may even have bugs in it. But as you’ll sometimes need to call non-thread-safe code from your multi-threaded code, this post presents a couple options for doing just that. So if you’re writing thread-safe code, kudos to you. By my observation, most code written is not thread-safe. When you write multi-threaded code, it’s important to be aware of whether the code in other libraries you call into is also thread-safe.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |