Hi On Thu, Jun 27, 2013 at 2:29 PM, Jiri Svoboda <[email protected]> wrote: > While there is more or less just one way of writing a single threaded ADT > (e.g. a hash table), there are a plethora of ways to synchronize access to > it - from one big lock (TM) to a very concurrent, lock-free, wait-free > (etc.) implementation. > > In most cases you don't need concurrent access and the one-big-lock > implementation does not bring much since in the majority of cases you > already have synchronization of access to the structure where this ADT is > contained.
IMO this is a good reason to have synchronization implemented as part of the structures themselves. You can have something more complex or a big lock and the user does not need to care. Even if exclusive access is guaranteed (implicitly or explicitly) few more locks that never block should not cause too much overhead. > It follows that normally you want to have a full complement of > single-threaded ADTs plus you might create a concurrent one based on > specific need. yes, but given that we don't use c++ templates, some code duplication can be avoided if we only provide thread safe structures (at least a big lock implementation). My only concern is with structures that allow direct access to elements without accessing the main structure first (like current linked list implementation). > Also synchronized data structures may vary by the synchronization mechanism > they use (fibril? thread?). I thought that fibril locks work transparently for threads too. However, the argument stands if the structure is to be shared between kernel and uspace (like fifo). having said that, I think that it does not hurt to have separate fifo (with a bit more functionality than today) and a blocking cyclic buffer (also available in adt/) built on top of it. Jan _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
