Not background worker, a thread, any thread.
were deprecated as unsafe. Basically, a thread can get a thread synchronization object and get paused before releasing it. It can easily jam the whole process or some threads of it until the process is terminated by some external process — the jammed process might not be able to terminate itself if some non-background threads are handing.
The safe implementation is similar behavior can be done using thread synchronization primitives
and classes derived from it. Please see:
In certain points, the thread should call the method
of some instance of this class. If the instance is in the wait state (reset), the calling thread will be switched of my OP and put in a wait (sleeping) state where it does not spend any CPU time. It won't be scheduled back to execution until it is waken up. It can be waken up by several events, such as
, timeout (if any), or, importantly, when some other thread signals the same instance of
, put it to signaled state (set). So, controlling the instance of
, some thread can throttle execution of some other thread, effectively implementing something similar to
, but in some fixed point of the code running by the thread.
Even if the thread is "paused" this way after it got ownership of some other event synchronization primitive object, if can always be aborted (see above), even if the instance of
holding the thread is kept non-signaled (reset).
Now, about cancellation of the thread.
is the asynchronous
method of thread termination, which many consider as unsafe (but this is important method which has not been deprecated). Indeed, you need to know perfectly well what are you doing, if you need to use it. Its mechanism is relatively new and extremely clever, based on the mechanism of exception seeding. Maybe this is not a place to discuss it here. Please see my past answers:
Close correcly the thread inside a dll
Problem with creating Process from dedicated thread
thread cancellation, please see this Microsoft article: