Thread-safe file locking

[Matt Brandt]

I am trying to get multiple threads to lock specific regions of a file.
However, since each thread has the same PID, it appears that a lock by
one thread does not block another thread from the same process.

How does one maintain file locking between sibling threads?

- Matt

 

[CBFalconer]

I am trying to get multiple threads to lock specific regions of a
file. However, since each thread has the same PID, it appears that
a lock by one thread does not block another thread from the same
process.

How does one maintain file locking between sibling threads?

Both threads and C++ are off-topic here (on c.l.c). We never heard
of a PID either. F'ups set.

 

[Ian Collins]

I am trying to get multiple threads to lock specific regions of a file.
However, since each thread has the same PID, it appears that a lock by
one thread does not block another thread from the same process.

How does one maintain file locking between sibling threads?

comp.programming.threads or an OS programming group would be a more
appropriate place to ask this. Neither C nor C++ have standard thread
or file locking support.

 

[Ron AF Greve]

Hi,

Maybe use a piece of code in your program to keep track of which thread
locked which region. Protrecting that piece of code with a mutex. Most
system support mutexes ( for instance sunos, MS-Windows and I believe linux)
..


Regards, Ron AF Greve

http://www.InformationSuperHighway.eu

 

[Rolf Magnus]

I am trying to get multiple threads to lock specific regions of a file.
However, since each thread has the same PID, it appears that a lock by
one thread does not block another thread from the same process.

How does one maintain file locking between sibling threads?

Both Standard C and C++ assume that there is nothing else running besides
your program, and both languages don't support threads. Therefore, there is
no concept of "file locking". To do what you want, you have to resort to
system-specific libraries.

 

[ks]

Both threads and C++ are off-topic here (on c.l.c). We never heard
of a PID either. F'ups set.

Is your advertisement off topic?

 

[Ian Collins]

Ron AF Greve wrote:

Please stop top posting. Your reply wasn't even a follow up to mine.

 

[Matt Brandt]

OK, well which ones then?

Both Standard C and C++ assume that there is nothing else running besides
your program, and both languages don't support threads. Therefore, there is
no concept of "file locking". To do what you want, you have to resort to
system-specific libraries.

 

[Walter Roberson]

OK, well which ones then?

Putting on my mind-reading hat....

....
...
...
...
Got it!

On your system, you need nerf_lock(), quizzle84(),
and (especially), StopTopPosting()

 

[Duane Hebert]

OK, well which ones then?

Boost has a thread library. Qt has one as well. Hard to say without
knowing what you use.

 

[Ian Collins]

Boost has a thread library. Qt has one as well. Hard to say without
knowing what you use.

Or even which language...

 

[Duane Hebert]

Or even which language...

Missed the cross post. If the OP is using C only,
pretty much lets out my suggestions...

 

[Gianni Mariani]

I am trying to get multiple threads to lock specific regions of a file.
However, since each thread has the same PID, it appears that a lock by
one thread does not block another thread from the same process.

How does one maintain file locking between sibling threads?

You should not be using file locking to protect between the same
threads. On the other hand, if the file handles are different, it may
be that file locking will work even within the same thread on different
file handles.

 

[Walter Roberson]

You should not be using file locking to protect between the same
threads. On the other hand, if the file handles are different, it may
be that file locking will work even within the same thread on different
file handles.

Unfortunately your answer to this off-topic question was not correct.
POSIX, for example, defines most attributes as being related to
the file descriptor (fd), not the file handle (FILE*) --
but when it comes to POSIX locking:

NOTES
Locks are on files, not file descriptors. That is, file descriptors
duplicated through dup(3C) (but not through fork(2), see the BUGS section
below) do not result in multiple instances of a lock, but rather multiple
references to a single lock.

This has some interesting and probably unintended consequences that can
result in early loss of the lock.

Correct locking is platform specific, and needs to be referred to
a platform specific newsgroup.

 

[Gianni Mariani]

Walter Roberson wrote:
....

Unfortunately your answer to this off-topic question was not correct.
POSIX, for example, defines most attributes as being related to
the file descriptor (fd), not the file handle (FILE*) --
but when it comes to POSIX locking:

What is a "file handle" ? That is also platform specific and somewhat a
generic term. The C stdio FILE* is not generally considered a file
handle and as you point out, the term "file descriptor" is in general
related to lower level I/O facilities in *NIX. Handles are however
related to win32 file I/O.

You will find much documentation refer to file descriptors as file
handles, but as you pointed out, file descriptors can refer to the same
instance of an open file (because of dup and dup2) and so it's a little
less useful.

....

Correct locking is platform specific, and needs to be referred to
a platform specific newsgroup.

So, yes, we're off topic, however, it's always good to let the OP know
why it's off topic in a more specific way.

The biggest incompatability however with file locking between *nix and
win32 is that overlapped locks in *nix are combined while on win32 they
are not. This means if you want your code to be portable, don't overlap
your locks.

 

[Richard]

Both threads and C++ are off-topic here (on c.l.c). We never heard
of a PID either. F'ups set.

Really? You must be a hobbyist programmer.

I have never heard of "F'ups".

"We" speak English is this news group. Kindly be courteous and consider
people whose first language is not English and would have problems
decoding your awful tendency to "jive" in your replies.

 

[Andre Kostur]

Really? You must be a hobbyist programmer.

I have never heard of "F'ups".

F'ups: Follow-ups. That particular contraction has been used on USENET
for decades now...