Thorsten Ottosen said: (by the date of Tue, 21 Nov 2006 13:16:29 +0100)
Also I'm sure that my new container will have to support threading. I was thinking about something like accessor methods that will lock for reading and lock for writing:
template <T> class my_superb_container {
// only one can write to item 'item_index', no reading allowed T& lock_write(int item_index);
// multiple reads of item 'item_index' are allowed, no writing const T& lock_read(int item_index); }
Lock will be released when leaving current block, in the destructor. (destructor of what? - still thinking about that).
It seems like a bad idea to mix threading into the container itself. Threading should be an orthogonal issue; once you have the container design worked out, threading can be added by your-self on top of that.
In my problem I don't need this container to me <algorithms> -capable. It is only to store data on which numerous threads will work on. Rarely adding or removing elements, mostly changing their content, and reading it. Therefore I don't want a single mutex for whole container. I want one thread to be able to write to one element, while other threads can work with other elements. Single mutex would block whole container just because one thread is working on a single element. I see no other option than to have another container of mutexes: one mutex per element. Is there anything else I can do? With this solution the threading cannot be orthogonal. Or I'm missing something? -- Janek Kozicki |