You can use a mutex to control access to the specific instrument or the entire bus, whatever you design it to do.
C# has some built-in facilities that may be easier to use than a mutex - a lock mechanism is a built into C# (lock is a C# keyword that uses the Monitor class). You lock an object and only one thread can own the lock at any one time. I'm pretty sure Microsoft implemented this as a critical section - it only works on threads within a single process. Mutex works across multiple processes, but is slower than a lock but you probably don't care. There's also a Mutex class you can use, and I suspect Microsoft wrapped a Windows API mutex to implement the class.
The way to use these is that every time a thread wants to communicate with the instrument of interest, have the thread grab the lock beforehand, and release it afterwards. A thread won't get ownership of the lock unless it's available (no other thread has it) so once you own the lock you're good to go. There's several methods / techniques available for checking if a lock is available, waiting for it, etc.
There are complexities of course, but if you are using only a single lock you can avoid most of them. With an interpreted environment like C# (the CLR) locking isn't as straightforward as with pure sequential code - mutual exclusion is a procedural concept, not an OO concept so doing mutex in an OO language is always a bit funky. Java has the same problem.
You might want to get a copy of C# 4.0 In A Nutshell ISBN 978-0-596-80095-6 - it is a very good reference and has a chapter on threads and synchronization that describes the use of locks and mutexes.
