Здравствуйте Dima2, Вы писали:
D>Представим что ф-я AddInternal(ptr) глобальная, которая соотвественно работает с глобальными переменными, и ты создаеш различные экземпляры твоего объекта в разных потоках, что тогда?
Глобальные объекты это плохо. Надо завернуть его в
класс запихав в private приделать нормальные функции
доступа и лочить mutex в этом классе уже внутри
функций.
Данный подход гарантирует что
1) никто не забудет полочить mutex
2) никто не полочит его на пол дня без необходимости.
И вообще на тему mutex-ов ты меня не переспоришь,
в программе над которой я сейчас работаю в среднем
100 потоков(в основном не мои правда, но как выглядит
работа с ними я очень хорошо представляю)
Т.е. вообщем главная идеология что объект должен
быть инкапсулировани и сам контролировать свою
синхронизацию.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте IT, Вы писали:
IT>Здравствуйте Anatolix, Вы писали:
IT>>>Какие потенциальные проблемы согут возникнуть при использовании Connection Point?
A>>Не совсем понял вопрос, я там особо проблем не вижу.
IT>Есть одна проблема, которая проявляется в распределённых приложениях, из-за которой иногда полностью приходится переписывать стандартную реализацию рассылки событий, а лучше от неё отказываться.
Понятно. С распределенным COM-ом опять же работал 7 лет назад
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Anatolix, Вы писали:
A>Глобальные объекты это плохо. Надо завернуть его в A>класс запихав в private приделать нормальные функции A>доступа и лочить mutex в этом классе уже внутри A>функций.
При чем тут глобальные объекты? Ты можеш вызвать какую-нить ф-ю из какой-либо библ. стороннего производителя, который тебе в описании говорит, что его библа не поддерживает никакой синхронизации.
Здравствуйте Anatolix, Вы писали:
IT>>Есть одна проблема, которая проявляется в распределённых приложениях, из-за которой иногда полностью приходится переписывать стандартную реализацию рассылки событий, а лучше от неё отказываться.
A>Понятно. С распределенным COM-ом опять же работал 7 лет назад
Я понял Речь идёт об обрывах соединений или подвисании клиентской программы во время вызова callback функции события. В данном случае провиснуть может вся система, т.к. сервер будет ждать возврата из callback функции клиента и отвалится только по таймауту, котоый в DCOM несколько минут.
С COM ясно, знания есть, но не глубокие, скорее всего на уровне прочтения книжек.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, Вы писали:
IT>Здравствуйте Anatolix, Вы писали:
IT>>>Несколько слов об этой самой заглушке можешь сказать?
A>>Ты хочешь слово маршалинг услышать? или proxy/stub?
IT>Я хочу услышать "очередь сообщений Windows" для STA
Это в принципе понятно если имеет право существовать только 1 поток
то это тот самый в котором выполняется очередь сообщений приложения,
там особо других средств синхронизации и нельзя придумать. Но на
поверхности это не лежит.
IT> и всё же выяснить, что в MTA синхронизацией занимается не COM,
а сам программист.
Это-то естественно, имеется ввиду что при вызове из MTA в STA
все будет сериализоваться. В других случаях это не делается т.к.
или не нужно (STA->STA) или пусть программист сам думает(MTA->MTA)
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Anatolix, Вы писали:
A>Это-то естественно, имеется ввиду что при вызове из MTA в STA A>все будет сериализоваться. В других случаях это не делается т.к. A>или не нужно (STA->STA) или пусть программист сам думает(MTA->MTA)
Здравствуйте Anatolix, Вы писали:
A>Microsoft Visual C++ — отлично — 3 года
Пройдёмся по средам.
Каким образом в студии собираются большие проекты состоящие из нескольких exe- и dll-модулей.
A>Borland C++ Builder — Guru — 5 лет. A>Borland Delphi — отлично — 1 год A>Borland Java Builder — прилично — 0.5 года
А по этим проходится не будет, я в них ни бум-бум.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, Вы писали:
IT>Каким образом в студии собираются большие проекты состоящие из нескольких exe- и dll-модулей.
Workspace.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Dima2, Вы писали:
A>>Глобальные объекты это плохо. Надо завернуть его в класс запихав в private приделать нормальные функции доступа и лочить mutex в этом классе уже внутри функций.
D>При чем тут глобальные объекты? Ты можеш вызвать какую-нить ф-ю из какой-либо библ. стороннего производителя, который тебе в описании говорит, что его библа не поддерживает никакой синхронизации.
А я об этом не спрашивал
Если нам не помогут, то мы тоже никого не пощадим.
A>Т.е. вообщем главная идеология что объект должен A>быть инкапсулировани и сам контролировать свою A>синхронизацию.
Идеологии бывают разные
И подходы к синхронизации тоже существуют разные — защищенный и синхронный (по терминологии Буча).
В первом случае обеспечение синхронизации ложится на плечи активных потоков, которые используют объект, во втором — объект обеспечивает ее сам.
Здравствуйте Dima2, Вы писали:
D>При чем тут глобальные объекты? Ты можеш вызвать какую-нить ф-ю из какой-либо библ. стороннего производителя, который тебе в описании говорит, что его библа не поддерживает никакой синхронизации.
Вот не вызываей ее из этой библиотека.
Сделай класс в котором будет защищенным образом
вызываться эта функция и вызывай ее только через
класс, тогда ты себя избавишь от 90% ошибок
до их появления. Нельзя отделять Mutex от
объекта который он защищает.
Т.е. я конечно понимаю что обходить грабли можно
легко но лучше их просто не разбрасывать.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Mink, Вы писали:
M>В первом случае обеспечение синхронизации ложится на плечи активных потоков, которые используют объект, во втором — объект обеспечивает ее сам.
Вот первый честно говоря череват ошибками и не особо нужен.
(там накладных расходов не много inline функции рулят)
Понятие 'инкапсуляция' в ООП прямо предполагает использование
втроого подхода.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Dima2, Вы писали:
D>Здравствуйте Anatolix, Вы писали:
A>>Это-то естественно, имеется ввиду что при вызове из MTA в STA A>>все будет сериализоваться. В других случаях это не делается т.к. A>>или не нужно (STA->STA) или пусть программист сам думает(MTA->MTA)
D>Неправильно.
Очень короткий и лаконичный комментарий.
аргументация будет?
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте IT, Вы писали:
IT>Здравствуйте Anatolix, Вы писали:
IT>>>Каким образом в студии собираются большие проекты состоящие из нескольких exe- и dll-модулей.
A>>Workspace.
IT>Блин, многословный ты наш, всё приходится из тебя вытаскивать. Что workspace? У него есть одна единственная полезная функция? Какая?
Я просто не понял что ты хочешь. Берешь несколько dsp засовываешь в
Workspace и делаешь Batch Build вот все и собралось.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Anatolix, Вы писали:
IT>>Блин, многословный ты наш, всё приходится из тебя вытаскивать. Что workspace? У него есть одна единственная полезная функция? Какая?
A>Я просто не понял что ты хочешь. Берешь несколько dsp засовываешь в Workspace и делаешь Batch Build вот все и собралось.
В каком порядке засовываешь, в алфавитном?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте Anatolix, Вы писали:
A>Я просто не понял что ты хочешь. Берешь несколько dsp засовываешь в A>Workspace и делаешь Batch Build вот все и собралось.
Он просто хочет от тебя добиться того, чтоб ты сказал, что сложные проекты собираются с помощию задействования механизма прописывания зависимостей.
Batch Build всего-то говорит, что собирать, а не в каком порядке, кого к кому линковать, etc. Расставляю зависимости между проектами, можно достигнуть порядка в сборке отдельных составляющих таким образом, что никогда ты не получишь по рукам от линкера из-за того, что некая static lib или dll не скомпилирована/собрана к сему моменту.
Если нам не помогут, то мы тоже никого не пощадим.
Речь идёт об обрывах соединений или подвисании клиентской программы во время вызова callback функции события. В данном случае провиснуть может вся система, т.к. сервер будет ждать возврата из callback функции клиента и отвалится только по таймауту, котоый в DCOM несколько минут.
