Boost has a very small collection of lockfree data structures:

http://www.boost.org/doc/libs/1_55_0/doc/html/lockfree.html

There is also libCDS:

http://libcds.sourceforge.net/

If you're only interested in Windows, they have the Parallel Patterns Library:

http://msdn.microsoft.com/en-us/library/dd492418.aspx

Otherwise just wrap the container access with mutexes and condition variables where necessary.

Thank you Peter - the problem is, few sections of customers do not really like 'movable, replaceable' components. Run-time components being such, always posed certain problems: such as,

1. Path resolutions (your software runs fine, but then all of a sudden crashes while loading some runtime component, because it just could not find it, despite being there on the disk somewhere, or Behold, it loaded an entirely different version !!!).

2. Security. (especially the LGPL3 forcing the 'replacement possibility clause') - being able to replace the dynamic runtime file with any other file of equal name, compromising the integrity is always a real threat - at least to the eyes of many customers. Not many OS these days take care of load-time version checks and integrity checks for dynamic runtime files.

The 'SxS' (side-by-side) technology (in Windows Xp onwards) is a good step in that direction, but Unix variants are still susceptible to this. One would have to write their own checksum verifications at load time - which increases the development costs (as well as performance penalties, since each dlopen or LoadLibrary is now have to be surrounded by validity checks).

3. Not to mention, the problem of hooking. I myself has written enough 'DLL Injection' libraries (e.g. http://gopalakrishna.palem.in/TracerApp.html ), to hook any arbitrary C++ run time components and modify their behaviour at runtime. (Hot-paching with Detouring is a very important technique to extend the life of your ever running web-servers in production)

I know, few of these problems are resolvable, with some patience and care - but for customers it translates to 'maintenance costs and training'. Why invest on solving the problems that have no reason to exist right in the first place - is their motto.

You may say, well there are other runtime components that they cannot runway from (such as OS runtime or GCC runtime etc.), why not add this one more - Unfortunately it will not fly with them. We can already hear them saying 'No thank you - we had had enough of DLL Hell'.

GK

http://gk.palem.in/

Gopalakrishna: You understand that by linking statically with a GPL library, that the code it links with becomes GPL - regardless of the platform it is running on.

To take Peter's example with LD_LIBRARY_PATH (on Linux) to the next level, you could install in /opt// (for example) with sudirectories for data, lib, and bin. Then install a wrapper shell script in /usr/bin, /usr/local/bin, or even /opt///bin which has one of its first lines as

LD_LIBRARY_PATH=${INSTALL_DIR}/lib:$LD_LIBRARY_PATH

export LD_LIBRARY_PATH

This would protect the actual binary from any system updates that change the version of a shared library on the system. I know that Windows attempts to avoid DLL Hell by now doing similar - rather than colliding in the same directory for all DLLs.

Regarding the address space, you can make a shared library ELF non-relocatable, just as well as you can make other assumptions precluding loading multiple instances of the same library into the same address space. Likewise, the point of a library might be to maintain a single instance for managing some kind of resource, so bringing multiple versions into the address space of a single process isn't necessarily a good thing, even if the module loader can technically handle it. I've personally seen this problem in a scientific code on Linux where two very separate modules were both accessing the hdf5 library, but ended up referring to different .sos - with highly peculiar results.

Anyway, as you noted, the true DLL hell in Windows could maybe be attributed to the lack of versioning for plain LoadLibrary without manifests in (mainly) the pre-Windows 2000 era. The OLE-related issues are more about the fact that by creating in-process OLE objects, you are dynamically bringing in "anything" into your process and it could be argued that the developer generally has less knowledge about what "anything" might be. Most of all, I would say that it is the curse of a mainstream platform. (Vaguely) similar issues have appeared in client-facing software written in Java with CLASSPATH. The causes are similar - some degree of lack of versioning and an environment where a little too developers a little too easily could bring code into their process. The problem is that those are the same aspects that made the environment highly productive in the first place.

To some extent, both the Windows and the Java case are also related to the practice of shipping compiled code. No configure or automake is done to adapt a build environment to the end user machine. Yeah, binary packages have been on Linux for ages, but those are far more specific in terms of what is referenced. Redistributing prebuilt Linux binaries force you to make far more assumptions about the environment on the receiving end.

Basically, in Win16 stuff, the same DLL was actually loaded once. In Win32/Win64, the same DLL *might* be backed by memory mapping to file. Loading an EXE and loading a DLL is the same thing (and you can actually add a linking flag for a module requiring it not to be supported by memory mapping). However, this works on file identity. If you load a library in one process, rename the file (so paging can still be backed by the original) and put another file in the same directory, with the same name, no DLL hell will ensue. The loader is also smart (eh, sane) enough to detect whether the preferred base address is occupied at load time. If so, memory mapping is NOT done for the code sections, and instead normal relocation is done. Collisions do not happen just because files have the same name. In short, the memory mapping is simply not a problem of library versioning issues, beyond the fact that a pre-existing file cannot be deleted. (It can be renamed, and in practice made to disappear, but the allocated clusters won't, until the parent process exits. Just like in Linux, all processes that have already loaded the shared objects will naturally not be hotpatched to use the updated code.)

The mmaps are per-process. The same address can refer to different versions of the same library, just as well as the same library can be loaded at different addresses in different processes. All "real" DLL hell issues (again, in anything after Win16, where you actually DID share address spaces) are due to a) the effects of someone putting another file with the same name in your library path. WinSxS is the platform-native way to handle that, unless you simply want to redistribute libraries in the directory of the binary instead, or b) different requirements of what library version should be loaded by the same process within the same address space. Imagine embedding two GUI controls from two libraries into the same application. Both controls can have dependencies on different versions of the same 3rd party libraries. Again, with winsxs you can still work this out to some extent, but some of those libraries actively require to be the only copy in the same process.

You may have a look at this one - http://libcds.sourceforge.net/

Boost