Andrey and Seth, thank you both for your responses. After thinking about this more, I probably do not want to transfer the lock. `pthread_mutex_unlock` failing if the calling thread does not own the mutex makes sense to me now, and I am very glad, Andrey, that you linked me to the pthreads reference. Looking at the Windows equivalent, `ReleaseMutex`, the Microsoft documentation also says that the function fails if the calling thread does not own the mutex. The project that I am working on is a cross-platform template library for spawning child processes (http://code.google.com/p/libnstdcxx/source/browse/branches/experimental/nstd...). Incidentally, yes, I am aware of a number of other libraries that provide similar functionality (libexecstream, pstreams, APL, dlib, pexl, pclasses, Platinum, STLplus, and the Boost Process proposal), but I have found aspects of these that I do not like, including lack of wide character support, no Windows implementation, or an interface that encourages non-portable programming. The structure of the template that I am working on, which I am calling `basic_process`, is header-only to support an arbitrary allocator. There are platform data classes which contain platform-specific data that is necessary to create child processes (handles, process information structures, etc.), the cross-platform `basic_process` definition, and a platform implementation header that fills in the details of the `basic_process` member functions. For the Windows port, which I am working on first, the platform data class basically looks like: class basic_process_data { boost::mutex mutex; // handles and a `PROCESS_INFORMATION` bool running; // http://lists.boost.org/boost-users/2009/09/51813.php void start() { boost::mutex::scoped_lock lock(mutex); boost::thread(mem_fun5_t(&basic_process_data::runner), this, boost::ref(lock), ...); } void runner(boost::mutex::scoped_lock& lock_, ...) { // setup, call `CreateProcess`, wait for the child process to finish } }; Of course, I am going to remove the first parameter to the `runner` function because I will no longer be trying to move the `scoped_lock`. The idea for moving the lock to the new thread that is running `runner` was to have an elegant solution to the problem of preventing multiple "runner threads" from being created, which would all modify the `basic_process_data` member variables in a very non-thread-safe way. Perhaps what I will do now is just use the `running` variable, which is `true` when the thread is running, to prevent multiple runner threads as well as allow me to determine if the runner thread is running (per the suggestion at http://lists.boost.org/boost-users/2009/09/51813.php). Also, I recently discovered a Windows function called `RegisterWaitForSingleObject` which might obviate the creation of a thread that justs waits for the child process to finish. Daniel