Уважаемые господа! Никогда ранее не сталкивался с многопоточностью, но пришлось...
Подскажите пожалуйста как правильно реализовать потокозащищенный ptr_vector...
Задача состоит в следующем:
Некий класс хранит список файлов.
Есть метод, который заполняет этот список (он должен работать в отдельном потоке), - здесь ничего сложного
Есть метод сортировки списка (сортировка по любому параметру списка - их 3: имя файла, дата создания, путь )
Есть Гуи - VirtualListViewControl... - для отрисовки этого списка...
Гуи должно работать в главном потоке...
И вот собственно вопрос:

Как правильно организовать ресурс, что бы пользователь имел доступ к гуи и сортировке, пока идет заполнение списка???

тоесть пользователь выбрал директорию для сканирования... запустился трид... и погнал набивать вектор...
паралельно гуи все это отрисовывает - мьютекс и как бы проблем нет.
но что с сортировкой делать???
Ведь пользователь может щелкнуть по какой либо из колонок... список еще не заполнен до конца, а нужно его уже сортировать...
Очень нужен совет.... 
Всем за ранее благодарен

полагаю, при сортировке, нужно останавливать заполнение пока не закончится сортировка.
т.е. перед вставкой элемента, пытаешься залочиться на condition`е. если _мьютекс_блокирующий_его_ при сортировке не залочен - то вставка происходит как обычно.
иначе, если началась сортировка, мьютекс который ее защищает лочится, и при попытке вставки(читай строку выше) залочишься на condition`е.
тут есть один нюанс - как сортировка закончится, не забудь разлочить мьютекс. а то будешь вечно висеть на вставке  

Это сообщение отредактировал(а) boostcoder - 26.5.2011, 14:33

если залочить контролы гуя пока идет заполнение, то можно обойтись одним мьютексом.

Добавлено через 6 минут и 8 секунд
ах да.. после того как произошла хоть одна сортировка по инициативе юзера, сохраняешь критерий сортировки и последующие вставки производишь дополнением(слиянием).

хммм. интересная задачка... можно попробовать след. образом:
Держать копии списка для каждого вида сортировки (не полностью структуры с именем, размером, etc. а только индексы из основного массива). При добавлении очередного файла в основной список лочить только эти копии, вставлять в них - в нужное место - новый индекс структуры, и разлочивать его. А в гую просто переключать списки, в зависимости от типа сортировки. Эдакий аналог БД с индексами.
М.б. не очень связно рассказал, но если понял - хорошо. Нет - спрашивай.

Всем огромное спасибо за быстрый отклик!



По ТЗ контролы Гуи должны быть доступны всегда!

Так же по ТЗ сортировка должна быть реализована стандартным алгоритмом std::sort (

Я подумал может сделать свою обвертку для ptr_vector, в которой реализовать потокозащищенные методы  
но не совсем представляю как это реализовать для итератора, что-бы исспользовать например for_each
собственно тогда сортировку можно будет проводить до последнего элемента который был добавлен в список
в момент нажатия контрола сортировки...  

так это гуд.
негуд то, что после первой сортировки все последующие вставки нужно вставлять в уже отсортированный контейнер. я для этого придется после каждой вставки заново сортировать. тормозить все будет жутко.
потому и говорю - слиянием.


я тоже.


а внутреннее устройство контейнера остается неизменным. при чем тут итератор?

Это сообщение отредактировал(а) boostcoder - 26.5.2011, 15:15

т.е. мой вариант даже не рассматривался ?
там вообще сортировать не нужно. просто вставлять int в отсортированный список int'ов. log2( N ) операций...
ну... как хотите  

может мы подумали о разных вещах...

я предполагал класс с приватным вектором и бустовым мьютексом, 
в класе переопределен интерфейс доступа к элементам вектора, в каждом методе свой lock - стандартный вызов метода вектора-unlock,
а вы о чем? Если можно пример... Я новичек в этом... по этому всегда рад умному совету! Если можно проще - подскажите плиз.   

все так.
только зачем сортировку выносить наружу? ;)
добавьте еще метод sort(predicate)

Большое спасибо! Кажется теперь вся картинка в голове собралась воедино))

Ваш вариант очень интересен, но ТЗ не я придумывал!
у меня в таске написано следующее:

3. Use one of the standard STL algorithms to sort the list. Or use container sorting methods instead
if any.

Все равно большое спасибо)

хмм. интересно, а чем

отличается от

?

насколько я понял имется ввиду следующее:

list<int>a;

standard STL algorithms:

#include<algorithm>

sort(a.begin(),a.end(),predicat)

а, container sorting methods:

a.sort(predicat)

только со вторым вариантом у меня както проблематично получалось, когда
boost::bind начинаешь юзать. 

а проблема-то в чем?

heavix, ясно. не знал, что у контейнеров есть метод sort. Щаз посмотрел - вроде только у list'а есть.

Может в твоём ТЗ в п.3 имеется в виду, что если уж использовать сортировку, то только из STL, а не велосипедную ? А если же ты не используешь её вообще, то и вариантов (велосипед vs STL) не будет