5

I'm new to thread programming (currently need to use win32 and c++ in a company project) and I just want to ask does entering the critical section means no context switching? does it mean that the thread will lock the resources until it leaves the critical section?

Also, I'm currently reading "Multithreading Applications in Win32" book and it seems good but is there a better-to-read and more up-to-date book for newbies to learn threading in win32?

Many thanks in advance ^_^

M.R.M
  • 540
  • 1
  • 13
  • 30
  • You probably don't need to worry about a more up-to-date book for Win32. Most of this stuff hasn't changed in over a decade. – Jonathon Reinhart Oct 24 '13 at 07:04
  • Thanx Jonathon Reinhart for this piece of info, you relieved me from wasting time searching for nothing. – M.R.M Oct 24 '13 at 07:28

1 Answers1

4

You're just a user-mode process, you can't prevent the OS from context switching to another process. What it means is no other thread in your process can enter the critical section until the first thread leaves it.

From MSDN (emphasis mine):

A thread uses the EnterCriticalSection or TryEnterCriticalSection function to request ownership of a critical section. It uses the LeaveCriticalSection function to release ownership of a critical section. If the critical section object is currently owned by another thread, EnterCriticalSection waits indefinitely for ownership.

And again, EnterCriticalSection says:

Waits for ownership of the specified critical section object. The function returns when the calling thread is granted ownership.

To answer the question of "will this prevent context switching between threads". No. Well, not really. Say you have two threads, A and B. A calls EnterCriticalSection and enters the CS. While he is using the shared resource in the CS, the OS can still context switch to thread B. B will continue to run as he did before, until he gets to the EnterCriticalSection call, at which point he will block.

Now how this blocking is implemented really up to Windows. But most likely, instead of "spinning" (Can I enter? No. Now? No. Now? No.) the OS will put that thread on "blocked" queue, and not schedule the thread until the thing he is waiting on (the CS) is available. At that point, he will be scheduled, and the call to EnterCriticalSection will succeed.

See also

Jonathon Reinhart
  • 132,704
  • 33
  • 254
  • 328
  • I meant context switching between threads. I have two threads and when each one reaches a certain function to execute I don't want it to be interrupted until it finishes it. So, in this case shall I use critical section for locking (there is no shared resource, just want to make sure no switching before the thread finishes its function)? – M.R.M Oct 24 '13 at 07:33
  • If there is no shared resource, then why are you trying to prevent one of the threads from running? – Jonathon Reinhart Oct 24 '13 at 07:35
  • because I'm outputting to the screen and sometimes while outputting a sentence on the screen by a thread it gets Interrupted by another thread to output another sentence. So, can you give me an advice how to prevent that? – M.R.M Oct 24 '13 at 07:52
  • 1
    Then your "shared resource" is the console, and you're doing the right thing by using a Critical Section :-) – Jonathon Reinhart Oct 24 '13 at 07:53
  • Well, thank u very much for your fast replies ^_^. It seems then that I misused the critical section since the problem remains. Thx again Jonathan. – M.R.M Oct 24 '13 at 08:17
  • Are you calling `InitializeCriticalSection` and passing the same object to Enter.. in both places? Did you look at that MSDN example code? – Jonathon Reinhart Oct 24 '13 at 08:21
  • For this to work, you have to make sure that all the code that writes to the console enter the same critical secton before writing. Correction: All the code that might be interrupted needs to enter the same critical section. – Stuart Oct 24 '13 at 08:34