Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Cyberax, Вы писали:

C>>Пример плохой. У нас тут самый обычный race condition — несинхронизированая работа с объектом. То что при этом у нас получится premature deletion — это уже просто детали.
WH>Тем не мение тут нужен либо внешний mutex либо конструктор копирования и оператор присваивания написанные в расчете на работу в разных потоках.
WH>В системах с GC (если не вспоминать про того жутика у которого запись/чтение указателей не атомарно) такой проблемы нет.

WH>А вобще в данном случае я наверное утечку памяти сделаю. Всеравно конфигурация кластера меняется реже чем обновляется ПО. Да и информация эта занимает всего несколько килобайт памяти.

ну можно и с InterlockedExchange etc. попробовать

Здравствуйте, BulatZiganshin, Вы писали:

WH>>А если серьезно есть ли варианты кроме того чтобы общию ссылку лочить?
BZ>использовать сообщения и отдельный тред который из обрабатывает?
Это в С++ то? Я уж лучше мутексом.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:


LCR> А если глянуть в rsdn.ru/forum/?group=decl, то может оказаться, что людям известны не только C*|Java.

Есть подозрение что достаточно взять любую ветку из философии количеством сообщений более 800 и увидеть там
1) Static vs dynamic
2) All vs c++
3) Nemerle vs all
4) А вот монады ..
5) J. просто J
6) Упоминание об языке с надежностью 99.9999%
7) Советы пойти учить BF и Whitespace

Если чего-то забыл, ногами не пинать

M>Если чего-то забыл, ногами не пинать

и ещё шаблоны против темплейтов

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, BulatZiganshin, Вы писали:

WH>>>А если серьезно есть ли варианты кроме того чтобы общию ссылку лочить?
BZ>>использовать сообщения и отдельный тред который из обрабатывает?
WH>Это в С++ то? Я уж лучше мутексом.

в C++ наверно вообще тружно что-то придумать. возможно, подойдёт отдавать процессу текущее значение, а при модификации создавать новое? или так фактически уже и делается?

посмотри ещё на всякий случай
The Little Book of Semaphores, Allen B. Downey [http://greenteapress.com/semaphores/downey05semaphores.pdf]

Здравствуйте, lomeo, Вы писали:

L>>>А как же LISP?
IT>>А как там?
L>Ну, в основном, без паттерн матчинга.

Можно примерчик?

Здравствуйте, Quintanar, Вы писали:

IT>>А как там?

Q>Там все как всегда — только s-выражения. Но, поскольку они просты по своей структуре, нужда в паттерн матчинге не столь очевидна.

Можно примерчик или ссылочку на примерчие? Иначе мне сложно будет убедится в справедливости твоего высказывания.

Здравствуйте, Трурль, Вы писали:

Т>Здравствуйте, VladD2, Вы писали:

VD>>Пролог создан в 1972 г. (http://en.wikipedia.org/wiki/Prolog)
VD>>ML создан в 1973 г. (http://en.wikipedia.org/wiki/ML_programming_language)

Т>ML создан в конце 70-х.

Открой ссылку, почитай.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Браво! Бис! Бис!

А что браво? Что бис? Ежу ведь понятно, что средства расширения Явы раны нулю. Максимум чем это может быть — еще одинм кмпилятором компиляторов.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>если ты имеешь в виду, что эти парсеры не может применять сам компилятор, то да. тут шансы есть только у ghc — parsec+template haskell+чтение данных из внешнего файла

Именно это и имею. Если внимательно читать дискуссию, то станет ясно, что речь идет о встроеных DSL-ях.

Внешний файл, кстати, тоже не катит. Это уже не встроенный ДСЛ, а скорее внешний.

BZ>но ведь можно применять и 2-stage scheme — сначала компилируем DSL в промежуточный язык, зтем компилируем этот apsr/ кстати, хаскел в таком режиме достаточно популярен, при этом прогпрамму можно сгенерить и сишную

Это очень сложная схема и в большинстве слуючае на нее просто не решаются. Создание независимого языка — это огромный труд. Его парсинг это только часть работы. Во встроенных DSL-ях ты можешь использовать возможности основного компилятора, что сильно упрощает решение проблемы.

Взять хотя бы недавнее осбуждение реализацию паттерна "Абстрактная фабрика". Как оказалось встренными средствами качественно ее можно легко решить только на Немерле (С++ и Ди позволили создать только сильно ограниченное решение). А создание внешнего DSL-я для данной задачи вообще бессмысленно. Ведь без анализа исходного кода это просто невозможно сделать.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>в C++ наверно вообще тружно что-то придумать.
А некоторые не будем показывать пальцем кричат что в С++ все хорошо
Я вобще мечтаю о чемто типа каналов из сингулярити. Они бы мне очень сильно жизнь упростили.
Особенно мне нравится то что там можно передовать end-point одного канала по другому.

BZ>возможно, подойдёт отдавать процессу текущее значение, а при модификации создавать новое? или так фактически уже и делается?
Именно так я и делаю. Иного решения чтобы не порушить все я не придумал.
Но есть проблема с временем жизни этого объекта (он довольно большой... строки, таблици...).
Тут 2 варианта:
1) Лочить расшаренную ссылку для того чтобы избежать преждевременного уменьшения счетчика ссылок. Я так сейчас и делаю.
2) Забить. Ибо утечка нескольких килобайт раз в несколько месяцев при 8 гигах оперативки... при том что ПО на сервере меняется чаще...

BZ>посмотри ещё на всякий случай
BZ>The Little Book of Semaphores, Allen B. Downey [http://greenteapress.com/semaphores/downey05semaphores.pdf]
Спасибо. Посмотрю.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Quintanar, Вы писали:

IT>>>А как там?

Q>>Там все как всегда — только s-выражения. Но, поскольку они просты по своей структуре, нужда в паттерн матчинге не столь очевидна.

IT>Можно примерчик или ссылочку на примерчие? Иначе мне сложно будет убедится в справедливости твоего высказывания.

(defmacro with-matrix (pats ar &body body)
    (let ((gar (gensym)))
        `(let ((,gar ,ar))
            (let ,(let ((row -1))
                (mapcan
                    #'(lambda (pat)
                        (incf row)
                        (setq col -1)
                        (mapcar #'(lambda (p)
                            `(,p (aref ,gar
                                ,row
                                ,(incf col))))
                             pat))
                    pats))
           ,@body))))

(defmacro with-array (pat ar &body body)
    (let ((gar (gensym)))
        `(let ((,gar ,ar))
            (let ,(mapcar #'(lambda (p)
                 `(,(car p) (aref ,gar ,@(cdr p))))
              pat)
            ,@body))))

(c) OnLisp.

WolfHound wrote:
> C>Пример плохой. У нас тут самый обычный race condition —
> несинхронизированая работа с объектом. То что при этом у нас получится
> premature deletion — это уже просто детали.
> Тем не мение тут нужен либо внешний mutex либо конструктор копирования и
> оператор присваивания написанные в расчете на работу в разных потоках.
Проблема возникнет только если последняя ссылка на умный указатель,
который передается по ссылке (!), находится в другом потоке. Весьма
необычная ситуация, согласись.

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

Ну и естественно, нужно использовать interlocked-функции для addref/release.

WolfHound wrote:
> Призренная задачка: Нужно расшарить неизменяемый объект (карта кластера)
> между потоками (Потоков много. Машина 4х процессорная.). Причем этот
> объект иногда обновляется (модифицировать по месту нельзя ибо будет
> нарушена целостность транзакции да и всеравно придется все внутренности
> объекта синхронизировать короче проблем будет очень много). При старте
> транзакции его нужно каждый раз перезапрашивать из централизованного
> хранилища. Просто удалить объект нельзя ибо его еще могут использовать
> запросившие рание потоки.
А передавать объект в транзакцию по значению нельзя? Тем более, что он
всего несколько килобайт. Или передавать указатель на него по значению.

Здравствуйте, IT, Вы писали:

IT>Можно примерчик?

Ой, да defmacro в гугле — и вперёд! Примеров полно Только я объясняю это не простотой s-выражений, как уважаемый Quintanar, а тем, что паттерн-матчинг нужен большей частью на очень низком уровне разработки типа.

Здравствуйте, Cyberax, Вы писали:

C>Проблема возникнет только если последняя ссылка на умный указатель, который передается по ссылке (!), находится в другом потоке. Весьма необычная ситуация, согласись.
Я параноик. Мне по работе положено. Тебе кстати тоже.

C>Проще всего ее решить, передавая умный указатель в поток по значению.
Это как?
Вобще у меня такак ситуация:
Есть интерфейс модуля некого многопоточного сервера.
Мой модуль реализует этот интерфейс.
При создании моего модуля я создаю этот самый объект и сохраняю ссылку на нго в своем модуле. Плюс еще некоторое колличество неизменяемых данных.
У этого интерфейса есть метод что-то типа

virtual Result handler(Context* context) = 0;

Этот метод дергается каждый раз когда приходит новый запрос.
Причем он дергается из разных потоков некоторого пула потоков.

Большинство запросов в самом начале копируют к себе ссылку и работают уже с локальной копией.
Но иногда приходит запрос который приводит к пересозданию этого объекта и изменению ссылки в модуле.
Вот из-за этого запроса мне и приходится городить мьютекс вокруг ссылки.
Иначе моя параноя меня загрызет.

C>Ну и естественно, нужно использовать interlocked-функции для addref/release.
Ну это само собой.

Здравствуйте, Quintanar, Вы писали:

Q>

Q>(defmacro with-matrix (pats ar &body body)
Q>    (let ((gar (gensym)))
Q>        `(let ((,gar ,ar))
Q>            (let ,(let ((row -1))
Q>                (mapcan
Q>                    #'(lambda (pat)
Q>                        (incf row)
Q>                        (setq col -1)
Q>                        (mapcar #'(lambda (p)
Q>                            `(,p (aref ,gar
Q>                                ,row
Q>                                ,(incf col))))
Q>                             pat))
Q>                    pats))
Q>           ,@body))))

Q>(defmacro with-array (pat ar &body body)
Q>    (let ((gar (gensym)))
Q>        `(let ((,gar ,ar))
Q>            (let ,(mapcar #'(lambda (p)
Q>                 `(,(car p) (aref ,gar ,@(cdr p))))
Q>              pat)
Q>            ,@body))))
Q>

Q>(c) OnLisp.

Жуть. И где здесь разбор входного AST?

WolfHound wrote:
> C>Проблема возникнет только если последняя ссылка на умный указатель,
> который передается по ссылке (!), находится в другом потоке. Весьма
> необычная ситуация, согласись.
> Я параноик. Мне по работе положено. Тебе кстати тоже.
Я настолько параноик, что такие ситуации (конкурентный вызов нескольких
методов объекта) заранее себе запрещаю. Плохое влияние Эрланга, однако.

> При создании моего модуля я создаю этот самый объект и сохраняю ссылку
> на нго в своем модуле. Плюс еще некоторое колличество неизменяемых данных.
> У этого интерфейса есть метод что-то типа
> virtual Result handler(Context* context) = 0;
> Этот метод дергается каждый раз когда приходит новый запрос.
> Причем он дергается из разных потоков некоторого пула потоков.
Сделай mutexex_ptr. Что-то типа:

template<class T> class mutexed_ptr
{
    intrusive_ptr<T> target_;
    mutex_t mtx_;
public:
    mutexed_ptr(intrusive_ptr<T> target)
    {
        target_=target;
    }
    ~mutexed_ptr()
    {
        delete target;
    }

    intrusive_ptr<T> swap(intrusive_ptr<T> val)
    {
        scope_lock lock(mtx_);
        intrusive_ptr<T> tmp=this->target_;
        target_=val;
        return tmp;
    }
    
    intrusive_ptr<T> get()
    {
        scope_lock lock(mtx_);
        return target_;
    }
}

Обернуть в политики и другие интересные штуки из Александреску по желанию.

> Большинство запросов в самом начале копируют к себе ссылку и работают
> уже с локальной копией.
> Но иногда приходит запрос который приводит к пересозданию этого объекта
> и изменению ссылки в модуле.
> Вот из-за этого запроса мне и приходится городить мьютекс вокруг ссылки.
> Иначе моя параноя меня загрызет.
А можно ли привязать по объекту-обработчику к каждому из потоков пула?

Здравствуйте, lomeo, Вы писали:

L>Ой, да defmacro в гугле — и вперёд! Примеров полно Только я объясняю это не простотой s-выражений, как уважаемый Quintanar, а тем, что паттерн-матчинг нужен большей частью на очень низком уровне разработки типа.

В Лиспе нет возможности конструировать типы так свободно, как в ML. Нет там повсеместного использования tuple и unions. Поэтому нет необходимости разбирать большие вложенные друг в друга конструкции (кроме списков), а значит нет необходимости в ПМ.
ПМ — это очень удобный способ не писать кучу сравнений и присваиваний руками, поэтому это довольно нужная фича.

Здравствуйте, Quintanar, Вы писали:

Q>ПМ — это очень удобный способ не писать кучу сравнений и присваиваний руками, поэтому это довольно нужная фича.

Я же с этим не спорю. Я говорю об области применения.