Best practice в создании свойств-списков объектов в COM в многопо

← →
Slym © (2007-12-07 12:43) [0]

Какой Best practice в создании свойств-списков объектов в COM в многопоточных приложениях?
Имеем многопоточное приложение и интерфейсы:
////Член списка ciInternal/tmSingle ITTestItem = interface(IDispatch) ["{350F0451-E8B4-42AE-A817-F83D112AD269}"] function Get_Data: Integer; safecall; property Data: Integer read Get_Data; end; ITTestItemDisp = dispinterface ["{350F0451-E8B4-42AE-A817-F83D112AD269}"] property Data: Integer readonly dispid 201; end; ////Сам список в нем же будет реализован и Enum ciInternal/tmSingle или ciInternal/tmApartment ? ITTest = interface(IDispatch) ["{9C3922E1-A24C-417D-B052-EE2940AFD628}"] function Get_Items(Index: Integer): ITTestItem; safecall; function Get_Count: Integer; safecall; function Add: ITTestItem; safecall; function _NewEnum: IUnknown; safecall; property Items[Index: Integer]: ITTestItem read Get_Items; property Count: Integer read Get_Count; end; ITTestDisp = dispinterface ["{9C3922E1-A24C-417D-B052-EE2940AFD628}"] property Items[Index: Integer]: ITTestItem readonly dispid 201; property Count: Integer readonly dispid 202; function Add: ITTestItem; dispid 203; function _NewEnum: IUnknown; dispid -4; end; ////Объект-владелец списка ciSingleInstance/tmApartment ITApp = interface(IDispatch) ["{426980CD-6720-4337-BE7A-82DA53343CBE}"] function Get_Test: ITTest; safecall; property Test: ITTest read Get_Test;//То самое свойство end;

1. Как реализовать возврат списка?
1.1. Создавать новую копию списка каждому запросившему, но при этом будут недоступны изменения в списке без запроса новой копии
1.2. Выдавать ссылку на имеющийся общий список, тогда как синхронизировать доступ к нему или оставить это для COM и играться настройками поточности апартмента (хотя в это с трудом верится)
2. О потоко безопасности члена списка позаботится COM есля я выставлю ТредМодельSingle?

← →
Сергей М. © (2007-12-07 12:57) [1]

> 2.

Ради упрощения алгоритма я бы положился на tmSingle

← →
Slym © (2007-12-07 13:10) [2]

Сергей М. © (07.12.07 12:57) [1]
tmSingle
тогда толучается
Создавать новую копию списка каждому запросившему

← →
Сергей М. © (2007-12-07 13:11) [3]

> Slym © (07.12.07 13:10) [2]

Не проще ли ввести пару методов Lock/Unlock ?

← →
Slym © (2007-12-07 13:14) [4]

хочется чтоб красиво было... в ADO видел Lock/Unlock? и это красиво (к ветке о красивости кода)

← →
Сергей М. © (2007-12-07 13:15) [5]

С др.стороны, почему бы и не копия ?

Можно же реализовать все это по образу и подобию транзакционного механизма в серверах-версионниках ..

И так ли уж обязателен список ? Может енумератор удобней будет ?

← →
DrPass © (2007-12-07 13:16) [6]

> Не проще ли ввести пару методов Lock/Unlock ?

Когда делаешь СОМ-объект, лучше по максимуму сделать его независимым от глупости/невнимательности разработчиков, которым он достанется. Поэтому я бы все-таки ограничился tmSingle

← →
Сергей М. © (2007-12-07 13:17) [7]

> в ADO видел Lock/Unlock?

В один и тот же ADO-интерфейс ты и не сунешься из многих потоков одновременно - отлуп тут же получишь)

← →
Slym © (2007-12-07 13:19) [8]

Сергей М. © (07.12.07 13:17) [7]
а мне какраз многопоточный синглетон в итоге нужен со списком объектов, ядро будет объекты обновлять, клиенты объекты обрабатывать

в идеале потом туда SQL присобачить какнить, типа как в WMI сделано "SELECT Item from core where item.ID=1" :) но это потом

> мне какраз многопоточный синглетон в итоге нужен

Тогда АДО как пример неудачен.

> ядро будет объекты обновлять, клиенты объекты обрабатывать

Механизм ивентов и/или колбэков тоже не подходит в кач-ве альтернативы списочному взаимодействию между сервером и контроллерами ?

Определился... Будет выдаваться копия списка как ciInternal/tmSingle, + метод типа Refresh(Requery) для обновления

Вопрос №2
Как Вы реализуете освобождение обектов при кросс-ссылочной организации взаимодействия объектов, т.е. разруливаете ситуацию с дедлоком освобождения ссылки 2х и более объектов друг на друга
Список хранит ссылки на итемы, но итемы тоже хранят ссылку на список

Сергей М. © (07.12.07 13:27) [10]
Механизм ивентов и/или колбэков тоже не подходит в кач-ве альтернативы списочному взаимодействию между сервером и контроллерами ?
это тоже конечно будет, но для начала плацдарм подготовлю...
будет 2 типа евентов: OnCountChanged и OnItemChanged

Сергей М. © (07.12.07 13:15) [5]
Может енумератор удобней будет
Без этого тоже никуда... возможно к объекту будут из всяких VB(А) конектится

Best practice в создании свойств-списков объектов в COM в многопо Найти похожие ветки