Locks, both those supported by .NET CompactFramework and those provided by the OS can be used to prevent some parts of code from being executed at the same time by multiple threads or to synchronize access to shared resources. They can’t give a thread exclusive usage of the CPU.
What you can do is to rise your thread priority to the highest level (0), using CeSetThreadPriority. This will grant that your thread will not be interrupted by other threads, unless they also run at priority 0. The thread could still be interrupted by interrupt service routines running in the kernel, but those usually don’t have a big impact on execution time.
In CE 7 and 2013 the scheduler assigns thread to all the cores, limiting a thread to a specific core is doable, but will impact its performances if the core is busy executing another thread, so, except for very specific use-cases, it’s better to let the scheduler manage threads on all the cores.
Consider also that rising priority to 0 can lead to some issues, your thread may get into an infinite loop preventing other thread in the system for running or cause a priority inversion (waiting on something owned by a low-priority thread and rising its priority) that can impact performances. Every time you call an OS API you may get into this conditions and things can get even worse on the .NET framework when the runtime may “freeze” all managed threads when doing garbage collection or other global operations.
If you give us “the big picture”, explaining what you need to do and what are the issues you are facing, we may able to provide a solution that does not involve high-priority threads or similar potentially risky operations.