Question 1
In the DoWork event handler of a BackgroundWorker, is it safe to access (for both reading and writing) member variables of the class that contains the BackgroundWorker? Is it safe to access other variables that are not declared inside the DoWork event handler itself?
Obviously DoWork should not be accessing any UI objects of, say, a WinForms application, as the UI should only be updated from the UI thread. But what about accessing other (not UI-related) member variables?
The reason why I ask is that I’ve seen the occasional comment come up while Googling saying that accessing member variables is not allowed. The only example I can find at the moment is a comment on this MSDN page, which says:
Note, that the BGW can cause exceptions if it attempts to access or modify class level variables. All data must be passed to it by delegates and events.
And also:
NEVER. NEVER. Never try to reference variables not declared inside of DoWork. It may seem to work at times, but in reality you are just getting lucky.
As far as I know, MSDN itself does not document any restrictions of this kind (although if I’m wrong, I’d appreciate a link). But comments like these do seem to pop up every now and again.
(Of course if DoWork does access/modify a member variable that could be accessed/modified by the main thread at the same time, it is necessary to synchronise access to that field, eg by using a locking object. But the above quotes seem to require a blanket ban of accessing member variables, rather than just synchronising access!)
Question 2
To make this into a more general question, are there any other (not documented?) restrictions that users of the BackgroundWorker should be aware of, aside from the above? Any “best practices”, perhaps?
The comments you quote in Question 1 are wrong. From a CLR point of view, it’s fine to access members of the form class from your BackgroundWorker (except, as you say, for controls, because they have thread affinity; but accessing non-Control members such as integers is fine). Yes, as you note, if you do this, then it’s up to you to synchronise access properly: it always is in a multithreading scenario. But bad synchronisation won’t cause exceptions as the first commenter suggests: it will just cause good old data corruption (which is so much better of course!). And it’s false to say that you’re “just getting lucky.” It’s not a matter of luck; it’s a matter of good synchronisation.
Why do I qualify this remark with “from a CLR point of view”? Firstly, because multithreaded access to state is difficult. So although it’s not problematic for the CLR, it may be problematic for the human being programming the CLR. Secondly, because if your form class contains lots of non-UI stuff that’s required by a BackgroundWorker, that may indicate that the application is poorly structured. It might mean that that stuff should be packaged up into an object, and the BackgroundWorker should call a method on that object rather than fiddling about with the state of the Form object.