EventDriven architectures are overwhelmingly easy to switch to
use threads, because the places between the events, for other activities,
are also good places for semaphores. But this doesn't work the opposite way.
Poorly architected systems might be hard to convert from threads to events.
So, either way, focus on good architecture.

''Well, my specific intention for this thread is for it to take care of caching the contents of a file in memory as my program is starting. The main thread can't wait that long, because the program is a Windows service and the service manager isn't willing to wait forever for my program to start.  I know I could do this other ways, but is there really a big disadvantage to spawning a thread to handle the caching of this file?''

Short term, no. Removing this thread won't force the architecture to improve.

Long term, use R''''''eadFileEx() in asynchronous mode. If you need notification
that the file arrived, you can multiplex the file event semaphore in with
the window messages using M''''''sgWaitForMultipleObjects().

Or start a window timer that wakes up and reads a small chunk of the file.
The file system will buffer the real file asynchronously, behind these
reads, meaning they shouldn't block the GraphicalUserInterface.

Notice the tutorials tend to teach threading _before_ they teach these
high-powered methods to cleanly avoid threads...

--Phlip