If I have two processes accessing a given registry key (off of HKLM), is it a good idea to wrap the logic in a Mutex?
The registry will make sure the actions are atomic, so you don't have to synchronize it yourself.
However, if you have multiple processes / threads accessing the registry at the same time, it doesn't make any guarantees about which happens first. Only that you won't get garbled data.
Edit: Further reading, see The inability to lock someone out of the registry is a feature, not a bug.
That depends on what you're communicating, and how time-critical the information is. Say, for example, that you have an app doing work and writing status results to a registry key, and another app reading that status and displaying it on-screen. In that case, I wouldn't bother with a mutex, as the reader will always get a value that "makes sense". What you're asking is really a fundamental question of concurrency design, I think.
Take a quick read of this Raymond Chen article. It explains that individual writes and reads against the registry are atomic. However, other locking is up to you as there's now way to hold a key open exclusively.
http://blogs.msdn.com/oldnewthing/archive/2009/03/26/9508968.aspx
Windows Server 2008 also has support for transactional access to the registry. Here's the overview at MSDN. And here's a blog post announcing it with some questions and answers.
As others have mentioned, individual operations are atomic. If you need to make a larger set of operations atomic, and you're targeting Vista or better, you can use the transactional registry support added in Vista.
Unfortunately, there is no direct managed support so you need to create wrappers.http://community.bartdesmet.net/blogs/bart/archive/2006/12/14/Windows-Vista-2D00-Introducing-TxR-in-C_2300_-_2800_Part-1_2900_.aspx shows how to P/Invoke these methods.