Two threads reading from same file?

I've got a Visual C++ application. It has two threads. Each thread needs
to read from the same data file (no writing is necessary).

No matter what I try, it appears that the two threads interfere with each
other's seek pointer. The reads succeed, but they are reading from the wrong
place in the file. Clearly, the seek pointers are getting altered by the
other thread.

I must be opening the files wrong. I've tried (in each thread):

_open()
fopen()
_open() followed by call to fdopen()
_sopen() followed by fdoen()

Question: What is the proper way to open a single file from two (or more)
threads so that each thread can read from the file simultaneously?

.

Relevant Pages

  • Re: Two threads reading from same file?
    ... Each thread needs ... >to read from the same data file (no writing is necessary). ... >other's seek pointer. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Two threads reading from same file?
    ... to read from the same data file (no writing is necessary). ... No matter what I try, it appears that the two threads interfere with each ... other's seek pointer. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Memory management and allocation
    ... > As I'm writing a piece of code that basically acts as a server and ... > memory management is a topic that is quite crucial. ... Or can I just allocate the variable ... Nor is it usually necessary to set the pointer to ...
    (comp.lang.c)
  • Re: FIFO File writing
    ... > To write a new record, read the 0th, form the pointer, seek there ... > binary operations, i.e. this is a binary file. ... > The file is vulnerable between writing the new record and writing ... > by first writing an invalid marker to the index record, ...
    (comp.programming)
  • Re: gdb not catching out-of-bounds pointer
    ... is also not defined by the C-standard, IOW: writing code in anything ... provided the library writer knows what the compiler writer guarantees ... etc.) that don't point into the same array than I would about the sort ... of pointer aliasing issue that started this sub-thread. ...
    (comp.unix.programmer)