When a thread is resumed, it doesn't restart, it resumes from the point in which it was interrupted.
So you have your writer thread waiting for the SDcard to respond to a command, but the sdcard is busy doing whatever an sdcard does, and will take 50ms to respond. In this case the writer thread must be in a loop waiting for the correct reply right?
While in that loop, the scheduler interrupts it and resumes a different thread (call it sensor thread), which takes 500uS to complete, and then goes to sleep for 100mS. When the sensor thread goes to sleep, the scheduler looks at what is the next active thread to run. The writer thread was not sleeping, it was waiting in a loop and was interrupted, so when resumed goes back to that same loop, and keeps waiting for the correct reply from the sd card.
That thread can be interrupted and resumed many times while in the loop, but eventually the sdcard replies back and the writer thread continues with it's writing process.
Does that clarify it?