Timeline for Static class ThreadPool implementation
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 12, 2014 at 21:21 | comment | added | svick | @MarcoAcierno Yeah, if you need to expose it, that's exactly the right way to do it. | |
| Jun 12, 2014 at 21:01 | comment | added | Marco Acierno |
i'm wrong or if you do something like: public static int FinishedThreads { get; private set; } the public would be ok?
|
|
| May 9, 2013 at 10:19 | vote | accept | rycle | ||
| May 6, 2013 at 0:27 | comment | added | svick |
@rycle No, the compiler certainly doesn't do anything like that. A better way is to write your code in a way that doesn't rely on checking Count at all.
|
|
| May 5, 2013 at 22:37 | comment | added | rycle | causing the next call to TryDequeue from this thread to find nothing inside? Or is the compiler smart enough to optimize both the Count check and the TryDequeue operations in the same critical code? Guess there's only one way to verify (IL). | |
| May 5, 2013 at 22:36 | comment | added | rycle | I think that the main reason I used ConcurrentQueue and also put a lock on it was in cases you want to check if the queue Count is some positive value and in the same breathe be able to manipulate it, like in these lines: if (_queue.Count > 0 && _maxThreads - _workers.Count > 0) { _queue.TryDequeue(out wcb); //if there's still work, dequeue something } What'll happen when you remove the surrounding lock there? Is it possible to get a positive value from _queue.Count then another thread dequeues right after it, | |
| May 5, 2013 at 22:00 | history | answered | svick | CC BY-SA 3.0 |