[interprocess] New snapshot and some explanations
Hi to all, I've uploaded to the boost repository and Boost.Vault/Concurrent Programming: (http://boost-consulting.com/vault/index.php?directory=Concurrent%20Programmi...) the first Boost.Interprocess version with documentation. The previous code had no documentation so this is the biggest change. You can find online documentation here: http://ice.prohosting.com/newfunk/boost/libs/interprocess The new documentation tries to explain better the basic operating system wrappers, like synchronization primitives, shared memory objects, essential file mapping, etc... The second part of the documentation is taken and adapted from Shmem. The library still needs some breaking changes, specially, error reporting with proposed boost system exception library. Since Boost.Interprocess offers a wide range of operating system primitives, I want to use the same error report machinery as Boost.Filesystem and Boost.Asio. For the moment, Boost.Interprocess throws interprocess_exception on error. Interesting additions are new named synchronization utilities and the use of move semantics to implement lock transfers, following this proposal: http://home.twcny.rr.com/hinnant/cpp_extensions/threads_move.html Boost.Inteprocess implements upgradable_mutex (a read-write mutex on steroids) with the addition of timed functions and several scoped lock types. You can read about them in the proposal and in Boost.Interprocess documentation: * Upgradable mutex http://ice.prohosting.com/newfunk/boost/libs/interprocess/doc/html/interproc... * Lock Transfers http://ice.prohosting.com/newfunk/boost/libs/interprocess/doc/html/interproc... The move semantics emulation is custom code, but obviously, I'm very interested in a Boost.Move library and I will update the code to use it if that's included in Boost. If the C++ committee chooses a different mutex proposal as the way to go, or modifies this proposal, I will adapt Boost.Interprocess to the new interface. *** Future work *** * Atomic initializations I'm still working on this. My first try has failed, because file locking is not thread-safe in POSIX (the file descriptor is a process-wide resource, and file locking functions don't mutually exclude threads from the same process). Adding an static thread-mutex in the code would not allow using Boost.Interproces in dll-s. Flyweight can't be used, because it relies on the old Boost.Interprocess global mutex to achieve this, so this is a recursive problem ;-). We'll see. * scoped_ptr vs. unique_ptr and move semantics Good old Shmem has it's own scoped_ptr (that has a custom deleter to be able to erase dynamically allocated shared memory objects) and Boost.Interprocess still has it, but I would like to drop it and use a unique_ptr that could be placed in shared memory. This can also substitute scoped_ptr for RAII tasks and we could use it to construct containers of unique_ptr's and avoid tedious hand-deletions. Move semantics could also be applied to other types, like shared memory strings and vectors. A vector of strings in shared memory with move semantics and in-place expansion should be killer. * Allocation algorithm I would want to add the option to allocate memory with alignment restrictions, so that we can request N bytes of memory with at least A byte alignment. This is a usual user request and I think that can be used for some new tricks. ...And of course, I must change the documentation according to the review. Thanks to all for all bug reports! Regards, Ion
Ion Gaztañaga wrote:
Hi to all,
I've uploaded to the boost repository and Boost.Vault/Concurrent Programming:
(http://boost-consulting.com/vault/index.php?directory=Concurrent%20Programmi...)
the first Boost.Interprocess version with documentation. The previous code had no documentation so this is the biggest change.
You can find online documentation here:
http://ice.prohosting.com/newfunk/boost/libs/interprocess
The new documentation tries to explain better the basic operating system wrappers, like synchronization primitives
Since there are already synchronization primitives in Boost.Thread and in numerous other Boost libraries which roll their own, would it not be efficacious for Boost to develop a separate synchronization primitive library which then could be used by all other Boost libraries.
Since there are already synchronization primitives in Boost.Thread and in numerous other Boost libraries which roll their own, would it not be efficacious for Boost to develop a separate synchronization primitive library which then could be used by all other Boost libraries.
Well, Boost.Thread and Boost.Interprocess aren't the libraries where this synchronization should go? Or you propose to merge all synchronization utilities in a new library? I think that Boost.Threads will have a revision once the C++ committee decides the thread API. Other libraries use their own synchronization primitives because they don't want to link an external library or they don't want to have dependencies. The first reason can be solved with a header only implementation of Boost.Thread utilities, but the second reason will always be there, I'm afraid. Anyway, I think that all Boost libraries should try to use already developed Boost components, and if those don't fill the requirements, request changes. A header-only thread library can be one of such requests. Regards, Ion
On Sun, 06 Aug 2006 21:03:14 +0200, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
Since there are already synchronization primitives in Boost.Thread and in numerous other Boost libraries which roll their own, would it not be efficacious for Boost to develop a separate synchronization primitive library which then could be used by all other Boost libraries.
Well, Boost.Thread and Boost.Interprocess aren't the libraries where this synchronization should go?
I think Edward was just proposing more coordination between library authors. I second that. Many times useful components are buried down into a detail/ subdirectory somewhere, waiting for someone to refine them and bring them to light. That usually never happens. When I come upon similar situations (components which might be useful on their own) I try to put them in the pending/ subdirectory, which at least makes them a bit more visible; but in fact that has not proven to be a solution.
[...]
Other libraries use their own synchronization primitives because they don't want to link an external library or they don't want to have dependencies. The first reason can be solved with a header only implementation of Boost.Thread utilities, but the second reason will always be there, I'm afraid. Anyway, I think that all Boost libraries should try to use already developed Boost components,
I strongly disagree. It is IMHO a cost/benefits issue. If I just want to output three or four messages to std::cout I don't bring in boost::format, even if it comes handy; the main cost indeed is adding another breakage source to my code, which largely outweighs the syntactical benefit. Similarly I won't use boost::program_options just to parse a few command line switches (typical in the facilities of our tools/ subdir). OTOH, if my code largely deals with files and directories then boost::filesystem is the preferred component to use; of course I won't go re-implementing things which are already better implemented there. -- [ Gennaro Prota, C++ developer for hire ]
Gennaro Prota wrote:
On Sun, 06 Aug 2006 21:03:14 +0200, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
Since there are already synchronization primitives in Boost.Thread and in numerous other Boost libraries which roll their own, would it not be efficacious for Boost to develop a separate synchronization primitive library which then could be used by all other Boost libraries. Well, Boost.Thread and Boost.Interprocess aren't the libraries where this synchronization should go?
I think Edward was just proposing more coordination between library authors. I second that. Many times useful components are buried down into a detail/ subdirectory somewhere, waiting for someone to refine them and bring them to light. That usually never happens. When I come upon similar situations (components which might be useful on their own) I try to put them in the pending/ subdirectory, which at least makes them a bit more visible; but in fact that has not proven to be a solution.
I was generally proposing that low-level synchronization primitives are a useful concept of their own which could be used by many other Boost libraries, and therefore should be their own Boost library. Obviously a synchronous primitives library could be used in any situation where asynchronous access to data is required. Of course synchronization primitives, by which I mean, for example, such well-known concepts such as mutexes, semaphores, events, locking mechanisms, atomic operations, and shared memory, are highly dependent on the operating system and therefore a good low-level synchronization primitive library, implementing most or all of the concepts above, must have knowledge of how each operating systems implement these concepts. I am aware of the shmem library, for shared memory, already although I have not used it yet. But all, or nearly all of the concepts above could benefit from a cross-platform Boost libary. My idea of such a library is strictly low-level and the common denominator idea. Then other Boost libraries, which use one or more of the implementations for any of the concepts mentioned, would be free, if necessary, to build on the low-level synchronization primitive's implementation without having to worry about cross-platform programming of their own more complicated needs.
Hi! "vectorstream" has "reserve" function instead of "resize" function like in documentation and previous versions :-) Dmitry Smirnov, Saint-Petersburg, Russia
Hi Dmitry,
"vectorstream" has "reserve" function instead of "resize" function like in documentation and previous versions :-)
Ooops. Documentation is not up-to-date. Resize was changed with reserve because a) I originally wanted to reserve memory, but not add characters to the stream. Shmem version called resize and set the new streams pointers, but this was not correct. b) I thought that adding characters to be stream should be done using stream functions, instead of though a vector resize. The idea in Interprocess is to have "reserve" to avoid reallocations when inserting new characters in the vector and I don't plan to include "reserve". Do you see it useful? Regards, Ion
Practically vectorstream is associated with "information packet". It should firstly to allocate memory with some maximum size (to send/receive through socket or shmem). So it seems no matter what "resize" or "reserve" will used. Ion Gaztañaga wrote:
Hi Dmitry,
"vectorstream" has "reserve" function instead of "resize" function like in documentation and previous versions :-)
Ooops. Documentation is not up-to-date. Resize was changed with reserve because
a) I originally wanted to reserve memory, but not add characters to the stream. Shmem version called resize and set the new streams pointers, but this was not correct.
b) I thought that adding characters to be stream should be done using stream functions, instead of though a vector resize.
The idea in Interprocess is to have "reserve" to avoid reallocations when inserting new characters in the vector and I don't plan to include "reserve". Do you see it useful?
Regards,
Ion
Hi, again! In errors.hpp header "fill_system_message" function isn't inline so will not compiled because of multiple definitions :-) Dmitry Smirnov Saint-Petersburg, Russia
participants (4)
-
Dmitry Smirnov -
Edward Diener -
Gennaro Prota -
Ion Gaztañaga