With the introduction on the hardware market of multi core processors, concurrent programming has become a very hot topic (at least more than it was before); synchronization techniques are still relatively new, when compared to other classic programming issues, and a lot of research is actually being done on them.

As for memory management, choosing among the solutions available at the moment is absolutely not a trivial task, since it has enormous implications in both performance and structural terms, and I don't feel like this is the right time to make such decisions.

So, for this first development release, our approach will be:

• implement only one kind of lock as an opaque type with a little set of handling functions; obviously, the internal code is OS-dependent (should be implemented as a mutex or a semaphore with exclusive access);
• the library won't be capable of starting or killing threads on its own.

Future directions

This temporary solution is tremendously rough and inefficient, but at least the resulting library will be thread-safe and it will be more or less clear which tasks are parallelizable.

Again, as in memory management, the approach followed in some future release will probably a mixed one. I hope to introduce, along with the classical mutexes, semaphores and spinlocks, support for more complex locking structures (read-write locks, etc.), new techniques (wait- and/or lock-free algorithms) and alternative (OS-specific?) solutions (benaphores).