Re: [boost] [interprocess] sharing memory between 32 bit and 64 bit Windows processes

Subject: Re: [boost] [interprocess] sharing memory between 32 bit and 64 bit Windows processes
From: Arno Schödl (aschoedl_at_[hidden])
Date: 2011-01-19 04:08:35

> > Hello Ion,
> >
> > I also need this functionality badly. Is there any chance of you
> > implementing it? Basically, using unsigned int instead of size_t and
> > int instead of ptrdiff_t, so the binary layout of shared memory is
> > always like in 32 bit, would in practice do the trick.

> I don't think that would work, compiler ABI might have other changes 
> (Empty Base optimization, new alignment requirementss etc.) for 64 bit 
> that would break everything. And I don't know the distance between 
> offset_ptrs created in the stack (eg temporaries) and those in shared 
> memory. If that distance (I think this depends on which address the OS 
> reserves to shared memory) is bigger than 2GB, then you are lost.

Do you know for a fact that MSVC 32-bit vs. 64-bit are so different, or just in general? We had our own hand-rolled mixed-bitness implementation of shared memory where I did not see ABI differences, but we may have been just lucky. Then we switched to boost.interprocess...

I still think even if there are ABI problems in certain scenarios, it is still worth getting to work whatever works. You cannot blindly throw objects into shared memory anyway. At least in Windows, modules are not guaranteed to be loaded at the same address, which breaks virtual function tables even if both processes have the same bitness.

Thanks for pointing out the 2GB problem. In our old implementation, we had the base address in a global variable because we only needed a single shared pool. We could create a special offset_ptr that knows its segment manager type (by template parameter), and a special segment manager that is required to be a singleton, with a static member to its base address. This special segment manager could still have an index template parameter so the user can have more than one of them, albeit decided at compile time. I don't think that many people need a runtime-determined number of pools.

> > If we implement it ourselves, would you support getting this into
> > boost? I cannot promise complete support. I already saw that
> > rbtree_best_fit has a problem because the ring list containing the
> > memory blocks needs to wrap around from the last block to the first.
> > Would porting Doug Lea's allocator be an option? It will be hard to
> > beat something that has been so thoroughly used and improved.

> If the code is good enough ;-) Porting DLMalloc is not easy, It 
> preallocates some bins for small allocation, and it relies on growing 
> heap memory. For shared memory this scheme is not very good because you 
> can't grow the existing space for all processes, but I think you could 
> adapt it. I don't understand the problem with rb_tree_best_fit.

Our old implementation was a hacked DlMalloc. We reserved x MBs of virtual address space, just like managed_windows_shared_memory, and simulated sbrk within it. The rb_tree_best_fit problem is the 2GB problem in a different form. The last memory block is a block of size (address_of_first_block-address_of_last_block) to walk the ring list from the last block to the first block.

Cheers,

Arno

--
Dr. Arno Schödl | aschoedl_at_[hidden]
Technical Director
think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany
http://www.think-cell.com | phone [phone] | US phone [phone]
Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306
Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl