apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonts, Richard" <Richard.Yo...@smss.sony.com>
Subject Dynamic memory at runtime update and question
Date Tue, 26 Jan 2010 19:54:31 GMT
After further experimentation, I have determined that the shared memory code does something
unexpected (at least, to me).  I have multiple processes {A..E} that each ask for a block
of memory using the apr_shm_create() call and convert it to a Node.  Each process requests
the memory from the same pool and gets the block at the EXACT same address, say X.  After
doing the apr_shm_baseaddr_get() each process can see the block, updates it, and adds the
new node to an array.

After all five processes have obtained the node and updated the array, it has exactly one
address in the first five array elements.  Therefore, every reference to the address after
calling apr_shm_baseaddr_get() points to the particular node that the process created (demonstrated
by the fact that its contents are the value the process set into it).  Upon the sixth attempt
to create a Node, process A calls create and obtains a different address; the pool allocater
knows that address X is already allocated to this process, so it allocates Y.  Then the next
four processes do the same, each getting Y for the total of two unique node addresses after
ten calls.

Log output:

[Tue Jan 26 10:50:09 2010] [error] [client] in log_transaction
[Tue Jan 26 10:50:09 2010] [error] [client] new node at 146435384 by 5709
[Tue Jan 26 10:50:09 2010] [error] [client] node @ 146435384 is 1
[Tue Jan 26 10:50:12 2010] [error] [client] in log_transaction
[Tue Jan 26 10:50:12 2010] [error] [client] new node at 146435384 by 5710
[Tue Jan 26 10:50:34 2010] [error] [client] in log_transaction
[Tue Jan 26 10:50:34 2010] [error] [client] new node at 146435432 by 5709
[Tue Jan 26 10:50:34 2010] [error] [client] node @ 146435384 is 1
[Tue Jan 26 10:50:34 2010] [error] [client] node @ 146435384 is 1
[Tue Jan 26 10:50:34 2010] [error] [client] node @ 146435384 is 1
[Tue Jan 26 10:50:34 2010] [error] [client] node @ 146435384 is 1
[Tue Jan 26 10:50:34 2010] [error] [client] node @ 146435384 is 1
[Tue Jan 26 10:50:34 2010] [error] [client] node @ 146435432 is 6

Relevant code:

static int log_transaction(request_rec* request) {
     List*      list;
     Node*      node;

     ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, request, "in log_transaction");
     list = (List*)apr_shm_baseaddr_get(shared_list);

     apr_shm_create(&(list->list[list->count]), sizeof(Node), NULL, list->pool);
     ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, request, "new node at %ld by %ld", (long int)list->list[list->count],
(long int)getpid());
     node = (Node*)apr_shm_baseaddr_get(list->list[list->count]);
     node->number = list->count;

     for (int i = 0; i < list->count; i++) {
           node = (Node*)apr_shm_baseaddr_get(list->list[i]);
           ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, request, "node @ %ld is %d", (long int)list->list[i],
     return DECLINED;

Does anyone have an idea why a given pool will return the same address to each process?  The
pool in question is the one passed to the post_config(apr_pool_t* pool, ...) function.  Would
not it be expected that the pool would NEVER return the same block (unless destroyed first)?
 Or, does this mean that the address of a shared memory block is determined both by a free
block and a process id?  If I understand the create call in apr_shm.c, mmap is what determines
the address of the block.  Why would each process get the same value back from it, but the
subsequent call by the same process correctly gets a different address?

Clearly I am missing something and have searched in vain to understand it.  All help is deeply
appreciated (and obviously needed).

Thank you,

Rich Yonts
sola fide, sola gratia, solus Christus, sola Scriptura, soli Deo gloria
****** ***** **

View raw message