run_id

[Beilei Sun]

Hi,

I am analyzing the NVML source code. Now, I am confused by the run_id in the pmemobjpool. What is the purpose to set run_id? 

In the pmemobj_runtime_init function, run_id is made unique by incrementing  the previous value, and then use the pmemobj_persist() function to writ to NVM. However, I didn't find any decrement operation on run_id.

It seems that, it is used to protect a pool against being accessed concurrently. However, I am not very clear about the way it works. Could anyone help to explain?

Thank you very much.

[Andy Rudoff]

Hi,

The run_id value is a generation number, increased each time a pmemobj pool is opened.  When a pmem-aware lock is acquired, like a PMEMmutex, the "runid" field in the lock is checked against the pool's run_id to see if this is the first use since the pool was opened and the lock needs to be initialized.

This is the mechanism that makes our pmem-aware locks return to their initial state each time the pool is opened.  So if you have a thousand locks held and the machine crashes, all those locks are dropped when the run_id is incremented (instead of having to somehow find all the locks and iterate through them).

-andy

[Beilei Sun]

Thanks Andy!

Is run_id built on the method of generation lock proposed by the NV-Heaps that provides concurrent accesses to an object? 

Since I saw Marcin said  that "currently it's not possible for pmemobj_open() on the same file", I thought run_id prevents concurrent access to the same object.

But now I doubt that after analyzing the _get_lock() function.

_get_lock(uint64_t pop_runid, volatile uint64_t *runid, void *lock,

int (*init_lock)(void *lock, void *arg), size_t size)

Because I found that even though runid doesn't equal to pop_runid, _get_lock tends to return a lock successfully, unless it fails to initiate the lock.

Does that mean the object could be accessed by different processes/thread concurrently?

 

在 2017年2月24日星期五 UTC+8下午10:25:57，Andy Rudoff写道：

[Beilei Sun]

"This is the mechanism that makes our pmem-aware locks return to their initial state each time the pool is opened"

---  what does "initial state" mean? 

在 2017年2月24日星期五 UTC+8下午10:25:57，Andy Rudoff写道：

Hi,

在 2017年2月24日星期五 UTC+8下午10:25:57，Andy Rudoff写道：

Hi,

在 2017年2月24日星期五 UTC+8下午10:25:57，Andy Rudoff写道：

Hi,

[Andy Rudoff]

Is run_id built on the method of generation lock proposed by the NV-Heaps that provides concurrent accesses to an object? 

Well, my goal was to provide the POSIX pthread locking calls on locks that automatically initialize the first time you use them.  It has been a while since I read the NV-Heaps paper but using generation numbers like this is certainly an idea that has been used many places before.

 

Since I saw Marcin said  that "currently it's not possible for pmemobj_open() on the same file", I thought run_id prevents concurrent access to the same object.

But now I doubt that after analyzing the _get_lock() function.

_get_lock(uint64_t pop_runid, volatile uint64_t *runid, void *lock,

int (*init_lock)(void *lock, void *arg), size_t size)

Because I found that even though runid doesn't equal to pop_runid, _get_lock tends to return a lock successfully, unless it fails to initiate the lock.

Does that mean the object could be accessed by different processes/thread concurrently?

The NVM Libraries currently do not support  multi-process access, just multi-thread access (and we've done some performance work to scale up with the number of threads in most cases).  We may add multi-process support in the future, depending on how strongly people ask for it.  To date, there haven't been many use cases for multi-process.  We use an exclusive file lock (via flock(2) on Linux) when a pool is opened to try to catch multi-process attempts and error out.

-andy

[Andy Rudoff]

"This is the mechanism that makes our pmem-aware locks return to their initial state each time the pool is opened"
---  what does "initial state" mean? 

The state is as if calls like pthread_mutex_init() have been called for you automatically.  The locks are in their unlocked state and ready for use.

-andy

 

[Beilei Sun]

Thanks andy!

在 2017年2月25日星期六 UTC+8上午8:50:23，Andy Rudoff写道：

[Beilei Sun]

Thanks Andy！ That really helps!

在 2017年2月25日星期六 UTC+8上午8:48:27，Andy Rudoff写道：

[Jace A Mogill]

Hi Andy,

The NVM Libraries currently do not support  multi-process access, just multi-thread access (and we've done some performance work to scale up with the number of threads in most cases).  We may add multi-process support in the future, depending on how strongly people ask for it.  To date, there haven't been many use cases for multi-process.  We use an exclusive file lock (via flock(2) on Linux) when a pool is opened to try to catch multi-process attempts and error out.

I am the author of a persistent store for shared objects between Javascript, Python, and C/C++ called Extended Memory Semantics (https://github.com/SyntheticSemantics/ems) which would cleanly map onto NVMlib's persistence and transactional semantics, but the source of parallelism is by definition process based.  If it helps build a case for process level support in the NVM library, it is already on the EMS roadmap.

                     -J

 

-andy

[Andy Rudoff]

Thanks, Jace.  That's a very interesting use case!  I'll check out the link you sent.

-andy