On Wed, 1 Sep 2004, Mark Crispin wrote: ; There is *nothing* wrong with altering a global in threaded code as long as ; you accept that that alteration affects every thread. This is a very useful ; attribute (beloved of those of us who wrote multi-forked code with shareable ; writable pages on TOPS-20). It is something that must be thoroughly ; understood; but it is not something to fear.
As I understand it, changing a global variable in threaded code without a lock can be a bad thing if another thread reads from the global while it is being changed (that may not be the case on a real-life system). However, as you say, changing driver parameters etc. would usually be done at the initialisation stage. ; > but there are a couple of places where race conditions could occur. For ; > example, there is code at the start of unix_header() which populates a ; > global STRINGLIST if it hasn't been done before. ; ; This is an excellent example. That global STRINGLIST is global for a reason. ; It should be a global constant, but it's complex enough to need code to build ; it. ; ; The only concern is whether another thread can run and join that code while ; the STRINGLIST is being built. For this, you need to understand how your ; thread library works. If thread switching only happens on I/O, you are safe ; since the only thing that code does is assignment and malloc(). I'm using Solaris so I can't rely on switching only happening on I/O - I'm also developing on a 4-way system so potentially four kthreads can be runnable and on a processor at once. Ideally, I'd want the code to be as portable as possible so I'm keen to make as few assumptions as I can. ; I'm not adverse to adding this sort of a mutex to this and the other places ; that initialize globals that are intended to be constants once set. That would be ideal! Thanks, Andy
