[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Antw: Re: LMDB test assertion failures on Linux/MIPS



Martin Lucina wrote:
Ulrich.Windl@rz.uni-regensburg.de said:
Hi!

I think a problem with your test program is that you don't wait for the write() thread to finish before you try to read the mmap(). See how locking on a producer-consumer (or reader-writer) relationship is usually implemented (If you don't have it ready, I could send you the algorithms).

That shoudln't matter.

More to the point, you don't wait for the write() thread to *start* - there's no guarantee that it will actually start running as soon as the barrier is released. A valid test has to know that the write() thread actually got scheduled and ran.

 The write thread opens the file descriptor with
O_DSYNC, and all the test program is trying to verify is that the mmap
eventually becomes consistent.  You can ignore the pthread_barrier stuff,
that just tries to eliminate thread creation time from the equation.

Now that I think about the output, there is a fairly obvious explanation
for the numbers - 1 means the writer thread got scheduled first.  However
I'm still not sure why the # of iterations on MIPS is so high - scheduling
resolution on the box maybe?

Martin




--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/