Здравствуйте, Сергей Губанов, Вы писали:

ГВ>>Какой смысл утверждать, что семафоры (сиречь, отчуждаемые объекты синхронизации) — это плохо...

СГ>Да ладно Вам... я утверждал немного другое. Плохо — это когда разрешено синхронизироваться на чём угодно, а не только на том, что специально для этого и было задумано, во что был вложен именно этот смысл.

Не вижу противоречия. Семафоры как раз и задуманы для того, чтобы на них можно было синхронизироваться. Строго говоря — это вообще неделимая синхронизационная сущность. По сути, exclusive-секция, это не больше, чем управление семафором на входе/выходе и обход ожидающих conditinal expression.

СГ>Например, в C# lock работает для всяких разных expression, а .Net-овский Monitor.Enter(object) работает для любых object, что может привести к трудно обнаруживаемым ошибкам, о которых уже сообщалось здесь

Автор: Oyster
Дата: 29.03.06

.

Ну, скажем так. К труднообнаружимым ошибкам (ТОО) обычно приводит хаотичный процесс разработки. Сами по себе особености того или иного языка влияют на возникновение ошибок весьма косвенно.

Как раз для того, чтобы избежать ТОО в случае многопоточного програмирования можно (и нужно, на мой взгляд) выделить планирование захвата ресурсов в отдельные процедуры, возможно — взаимосинхронизированные (рассуждение с a1...d). В случае с "оберонским" подходом к реализации — выделить независимый объект, у которого все методы будут exclusive. В общем, такое разделение ничем не отличается от подхода, когда мы выделяем набор семафоров, а работу с ними помещаем в отдельные процедуры или классы. Есть только один недостаток — иной раз может потребоваться несколько таких объектов, например, по соображениям, связанным с наличием разных модулей и т.п. И вот тут-то будет не очень хорошо, поскольку в случае отчуждённых семафоров достаточно следовать политике захвата ресурсов, а в случае "оберон-подхода" придётся всякий раз модифицировать сам управляющий объект (LSP-violation? похоже, но не уверен).

Ну, скажем, для приведёного примера (он слегка надуман, ну ладно) в случае традиционного языка можно было бы поступить так:

Semaphore s_a1;
Semaphore s_a2;
Semaphore s_a1_a2;
SomeClass a1;
SomeClass a2;

// Далее, исполняем политику, в которой сказано, что при работе с a1 и a2 сначала следует залочить s_a1_a2
void func_a1a2()
{
  Guard g(s_a1_a2);
  Guard g1(s_a1);
  Guard g1(s_a2);
  // Много-много чего-то.
}

void func_a1()
{
  Guard g1(s_a1);
  // Здесь будет что-то про a1
}

Теперь, если нам захочется добавить какой-нибудь a3, с которым нужно работать вместе с a1 и a2, то можно поступить так:

Semaphore s_a3;
Semaphore s_other_a3;
SomeClass a3;

void func_a123()
{
  Guard g123(s_other_a3);
  Guard g3(s_a3);
  Guard g12(s_a1_a2); // Условно говоря, это - наследование имеющейся политики блокировок.
  Guard g1(s_a1);
  Guard g2(s_a2);
  // Интенсивно юзаем a1, a2, a3
}

И наконец, упростим себе задачу отслеживания политики — сделаем так, чтобы блокировка одного семафора гарантированно означала блокировку ряда других семафоров. Сформируем комплексные управляющие объекты:

class MultiSemaphore : public LockableObject
{
    Semaphore s_my_;
    /* Список адресов остальных семафоров */ others_sems_;
  public:
    MultiSemaphore(Semaphore *p1, ...)
    {
      /*читаем в цикле через va_arg*/ other_sems_.add(other_ptr);
    }
    //
    void Lock()
    {
      s_my_.Lock();
      /* Крутим цикл по списку others_sems_, от начала в конец */
      others_sems_[i]->Lock();
    }
    void Unlock()
    {
      // NB! Действуем строго в обратном порядке по отношению к Lock()!
      /* Крутим цикл по списку others_sems_, из конца в начало */
      others_sems_[i]->Unlock();
      s_my_.Unlock();
    }
}

Тогда задача отслеживания политики блокировок несколько упрощается:

Semaphore s_a1;
Semaphore s_a2;
MultiSemaphore s_a1_a2(&s_a1, &s_a2, 0); // 0 - терминатор списка

void func_a1_a2()
{
  Guard g(&s_a1_a2); // гарантируем себе, что блокировка проведена правильно.
}

void func_a1()
{
  Guard g(&a1);
  // ...
}

И когда добавляем a3 и s_a3:

Semaphore s_a3;
MultiSemaphore s_other_a3(&s_a3, &s_a1_a2, 0);

void func func_a123()
{
  Guard g(&s_other_a3);
  // Всё! В этой точке мы имеем корректно заблокированый контекст.
}

Дальше решение можно усложнить — внедрить, например, в MultiSemaphore алгоритмы предсказания блокировок и т.п. В общем — можно будет поиметь славный fun и приход.

При этом, что важно, нам не понадобилось менять уже имеющийся код, как это произойдёт в случае с "диспетчерским" объектом. Случаи патологической глупости и попыток захвата s_a1 поперёд s_a1_a2 я не рассматриваю. Также, впрочем, не буду апеллировать к возможности сделать семафор средствами самого Оберона, поскольку таким образом решение задачи на Обероне сводится к "классике".

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

ГВ>>Здесь у тебя получается слишком много блокировок. Вернее, на каждый вызов MethForA1A2 происходит 3 захвата/освобождения объекта синхронизации.
S>Точнее по одному захвату трех разных объектов. Что в этом плохого?

Да, верно. Притом захваты подчинённых объектов (a1 и a2) выполняются при каждом вызове их методов. Я, в общем-то, когда выдумывал пример, то предполагал, что захват агрегата a1+a2 нужен для какой-то, достаточно объёмной работы. Если нужно всего-то по одному разу вызвать методы a1 и a2, да ещё и с промежуточным храненим данных, то здесь, ИМХО, дополнительно блокировать весьт агрегат не нужно.

А если производится большой обмен данными (скажем — десяток вызовов a1 и столько же — a2), то можно здесь хорошо завалить производительность из-за постоянных lock/unlock на каждый вызов.

S>Если мы поместим MethForA2 внутри D, то количество блокировок уменьшится, но одновременно увеличится эффективный размер критических секций. Т.е. клент для MethForA2 будет ждать все время операции MethForA1A2, хотя ему до этого никакого дела нет.

Верно. Поэтому в таких методах нужно бороться с непредсказуемыми побочными эффектами. Например — не вызывать MessageBox. Насчёт увеличения длины критической секции — согласен, но такова плата за повышение общей производительности благодаря отказу от лишних блокировок/разблокировок.

S>По сути к этому:
S>

СГ>>Лочиться только на самом себе логически следует из объединения ООП и многопоточности:
СГ>>1) Все данные инкапсулированы внутри объектов.
СГ>>2) Доступ к любым данным осуществляется только с помощью методов объекта.
СГ>>3) Для синхронизированного (эксклюзивного) доступа к данным используются эксклюзивные методы (т.е такие методы, блоки кода в которых залочены на this).

S>стоит добавить пункт про распределение обязанностей. Если обязанности (данные/методы) распределены между объектами оптимальным образом, то в чем проблема в использовании lock(this)?

Да-да. Вопрос как раз в критериях "оптимальности".

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

ГВ>...поскольку таким образом решение задачи на Обероне сводится к "классике".

Не буду возражать. Я не против классики.

Кстати, вот мой вариант решения Вашей задачи про MultiSemaphore, но через Монитор.
Заранее извиняюсь, что не на Active Oberon, а на C#. Но на Active Oberon этот текст перепишется почти 1:1 заменяя:

lock (this) и Monitor.PulseAll(this) ---> BEGIN{EXCLUSIVE} ... END
while (this.IsBusy(indexies)) System.Threading.Monitor.Wait(this); ---> AWAIT(this.IsBusy(indexies))

ну, и лишаясь синтаксического сахара навроде params и foreach

namespace Test
{
  public sealed class MultiSemaphore
  {
    private readonly bool[] busyFlags;

    public MultiSemaphore (int count)
    {
      this.busyFlags = new bool[count];
    }

    private bool IsBusy (params int[] indexies)
    {
      foreach (int i in indexies) if (this.busyFlags[i]) return true;
      return false;
    }

    public void Enter (params int[] indexies)
    {
      lock (this)
      {
        while (this.IsBusy(indexies)) System.Threading.Monitor.Wait(this);
        foreach (int i in indexies) this.busyFlags[i] = true; // заняли
        System.Threading.Monitor.PulseAll(this);
      }
    }

    public void Exit (params int[] indexies)
    {
      lock (this)
      {
        foreach (int i in indexies) this.busyFlags[i] = false; // освободили
        System.Threading.Monitor.PulseAll(this);
      }
    }
  }
}

...я намеренно здесь не написал проверок индексов на принадлежность интервалу 0..this.busyFlags.Length-1, это конечно надо сделать в реальном коде, а этот код демонстрационный

Использование:

  MultiSemaphore sem = new MultiSemaphore(10000);

  // ...

  sem.Enter(26, 38, 17, 237, 266, 1001);
  // работа с объектами номер 26, 38, 17, 237, 266 и 1001
  sem.Exit(26, 38, 17, 237, 266, 1001);

Здравствуйте, Сергей Губанов, Вы писали:

СГ>while (this.IsBusy(indexies)) System.Threading.Monitor.Wait(this); ---> AWAIT(this.IsBusy(indexies))

точнее, наоборот: AWAIT(~this.IsBusy(indexies))

Здравствуйте, Сергей Губанов, Вы писали:

ГВ>>...поскольку таким образом решение задачи на Обероне сводится к "классике".
СГ>Не буду возражать. Я не против классики.

А как это вяжется с рассуждениями о недостатках традиционного подхода?

Разница в том, что залочится в C# можно на любом (чужом) объекте (быть может, на ровном месте неожиданно заработав deadlock), а в Active Oberon — только на самом себе (только на this).

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

ГВ>А как это вяжется с рассуждениями о недостатках традиционного подхода?
ГВ>

ГВ>Разница в том, что залочится в C# можно на любом (чужом) объекте (быть может, на ровном месте неожиданно заработав deadlock), а в Active Oberon — только на самом себе (только на this).

В моём примере MultiSemaphore разьве лок не на this делается?

На this.

Язык C# (в частности) и .Net (вообще) разрешают кому угодно другому напрямую залочится на объект MultiSemaphore ms следующим локом:

lock (ms)
{
...
}

не обращая внимания на (в обход) специально предусмотренного ms.Enter() и ms.Exit()?

Разрешает. И это есть дыра.

Мои претензии — к этой дыре.

Здравствуйте, Сергей Губанов, Вы писали:

ГВ>>А как это вяжется с рассуждениями о недостатках традиционного подхода?
СГ>В моём примере MultiSemaphore разьве лок не на this делается?
СГ>На this.

Угу. Но наличие методов Enter/Exit как раз и лишает блокировку локальности.

СГ>Язык C# (в частности) и .Net (вообще) разрешают кому угодно другому напрямую залочится на объект MultiSemaphore ms следующим локом:

СГ>lock (ms)
СГ>{
СГ> ...
СГ>}

СГ>не обращая внимания на (в обход) специально предусмотренного ms.Enter() и ms.Exit()?
Хмм... Цитата из MSDN:

Monitor.Enter
[...]
Invoking this member is identical to using the C# lock statement.

Я чего-то не понимаю... Или претензия к тому, что один поток может залочиться на семафор "снаружи", а другой в это время позовёт его методы не выполнив lock(semaphore)?

СГ>Разрешает. И это есть дыра.
СГ>Мои претензии — к этой дыре.

Так создавая объект "Семафор" на Обероне мы и создаём ту же самую "дыру". Даже не в профиль. То есть, сводим ряд задач к привычному "дырявому" базису. Семафор тоже может "залочить" кто угодно — для того он и создаётся, собственно.

Здравствуйте, Сергей Губанов, Вы писали:

Поторопился с ответом, ввело в заблуждение совпадение названий Monitor.Enter и MultiSemaphore.Enter. Действительно, не следует путать lock(ms) и ms.Enter/ms.Exit. В общем — да, можно считать подобное "дырой", хотя опять-таки, палка сия о двух концах. Ну так здесь дыра не в "нелокальности" блокировок, а в том, что объектом синхронизации может выступать всё что угодно, а не только специально предназначенные для этого сущности (семафоры, мьютексы, критические секции и т.п.).

Тогда, пожалуй, что соглашусь — риск налететь на deadlock при таком подходе повышается. Но, повторюсь, дело здесь не в "нелокальности", а в том, что, фактически, у нас количество семафоров равно количеству объектов (+ N * количество_объектов_value-типов за счёт боксинга).

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

S> sync block используется не только для блокировки но и например для дефолтного GetHashCode итд

Сдаётся мне, что в версии 2 это уже не так. Хотя, нужно проверить по коду SSCLI 2.0.

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

ГВ>Так создавая объект "Семафор" на Обероне мы и создаём ту же самую "дыру". Даже не в профиль. То есть, сводим ряд задач к привычному "дырявому" базису. Семафор тоже может "залочить" кто угодно — для того он и создаётся, собственно.

Тут есть маленький штрих. lock() позволяет извне залочить любой объект (ну, ассоциированный с этим объектом мьютекс, неважно). А если мьютекс является внутренней принадлежностью объекта (на уровне языка, как в Обероне, или на уровне библиотек, как в большинстве других языков), то он и только он решает, кому и как позволено лочить. Инкапсуляция, понимаш.

class Something
{
private:
  mutable mutex guard_; // чтобы сделать Something монитором, нам нужно владеть мьютексом...
public:
  void foo()
  {
    mutex::scoped_lock exclusive(guard_); // ... и пользоваться им
    .....
  }

  // если любишь в жизни риск, форматируй жёсткий диск
  mutex& guard() const { return guard_; }
  void lock() const { guard_.lock(); }
  void unlock() const { guard_.unlock(); }
  // никто не заставляет отдавать ручки наружу - только добрая или злая воля автора
}

Если мы на Обероне создали объект "мьютекс" и пользуемся им — то пользователь должен быть очень настойчивым и глупым, чтобы 1) напихать эти мьютексы во все структуры и 2) лочить их направо и налево.

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

ГВ>>Так создавая объект "Семафор" на Обероне мы и создаём ту же самую "дыру". Даже не в профиль. То есть, сводим ряд задач к привычному "дырявому" базису. Семафор тоже может "залочить" кто угодно — для того он и создаётся, собственно.

К>Тут есть маленький штрих. lock() позволяет извне залочить любой объект (ну, ассоциированный с этим объектом мьютекс, неважно).

Угу. В общем, я с этим согласен

Автор: Геннадий Васильев
Дата: 31.03.06

и вот, почему:

Тогда, пожалуй, что соглашусь — риск налететь на deadlock при таком подходе повышается. Но, повторюсь, дело здесь не в "нелокальности", а в том, что, фактически, у нас количество семафоров равно количеству объектов (+ N * количество_объектов_value-типов за счёт боксинга).

В общем, мои позиции таковы:

1. Защита от deadlock-ов начинается с планирования синхронизаций и построения графа блокировок.
2. Метод реализации должен выбираться в соответствии с задачей и имеющимися языковыми средствами.
3. Реализация не должна разрушать план синхронизации.

Почему я согласен с СГ в той части, что в .Net есть "дыра"? Потому что очень легко нарушить граф синхронизации — зацепив любой объект. То есть, нужно вводить ограничения на использование определённых конструкций языка. В принципе, ничего страшного тут нет — решаемо.

Почему я не согласен с СГ в той части, что лучший способ управления — самоблокировка? Потому что иначе не было бы нужды делать семафоры в Обероне. Я не сомневаюсь, что немалую часть задач можно решить посредством EXCLUSIVE/AWAIT, просто где-то таких exclusive нужно два (захват/отпускание). С другой стороны, не всегда синхронизируемые процессы могут принадлежать одному объекту или классу.

Вывод: и в .Net дырка может проявиться, и апологетов ООП слушать ни к чему. В сухом остатке — свой мозг и планирование синхронизаций.

Вот так или примерно так.

СГ>Заранее извиняюсь, что не на Active Oberon, а на C#.

На Zonnon:

object MultiSemaphore;

  var busy: array 1000 of boolean;

  procedure IsBusy (s: array of integer): boolean;
    var i: integer;
  begin
    for i := 0 to len(s)-1 do
      if busy[s[i]] then return true end
    end;
    return false
  end IsBusy;

  procedure SetBusy (s: array of integer; val: boolean);
    var i: integer;
  begin
    for i := 0 to len(s)-1 do busy[s[i]] := val end
  end SetBusy;

  procedure {public} Enter (s: array of integer);
  begin {locked}
    await ~IsBusy(s);
    SetBusy(s, true)
  end Enter;

  procedure {public} Exit (s: array of integer);
  begin {locked}
    SetBusy(s, false)
  end Exit;

end MultiSemaphore.

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

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

SM>>Разумное самоограничение ВСЕХ программистов в проекте и все ок. Вот только иногда проще заставить программистов работать со средством разработки принципиально запрещающем что-то делать, нежели добится разумного самоограничения.

Д>В данном случае сделать глобальный поиск по исходникам и раздать звиздюли по его результатам — совершенно несложная задача

А если код протестирован временем и его нельзя трогать? Знаете менеджеры иногда готовы увольнять программистов за рефакторинг. Да как будем боротся с наведенными эффектами? А если так пишет единственный разработчик разбирающийся в проекте? Как то вы предлагаете простое организационное решение, которое в жизни очень часто не работает.

SM>>Хотя бесусловно обсуждаемый момент может быть не достаточно важной причиной для смены средства разработки и т.д.

Д>скорее — не может быть достаточно важной причиной. Тем более что надо не только менять средство разработки, но еще и переписывать весь код.

Может при прочих равных. Вы ведь не против типизации? Или все таки против?

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

SM>А если код протестирован временем и его нельзя трогать? Знаете менеджеры иногда готовы увольнять программистов за рефакторинг.

Если катастрофически нет времени в данный момент — да, они правы. А в остальных случаях увольнять надо таких менеджеров.

SM>Да как будем боротся с наведенными эффектами?

Какие еще наведенные эффекты могут быть от замены lock(this) на lock(syncObject)?

SM>А если так пишет единственный разработчик разбирающийся в проекте?

Уволить всех, влючая этого разработчика. Или валить к чертовой бабушке из такого проекта. Или оба варианта вместе.

SM>Как то вы предлагаете простое организационное решение, которое в жизни очень часто не работает.

Вот это конкретное решение, в этом конкретном случае? Ты проверял?

Д>>скорее — не может быть достаточно важной причиной. Тем более что надо не только менять средство разработки, но еще и переписывать весь код.

SM>Может при прочих равных. Вы ведь не против типизации? Или все таки против?

А что — типизация? Почти в любом языке есть конструкции, которые не имеют прямого аналога в другом языке, и вообще реализуются с трудом. К тому же язык — это не только язык, но еще и платформа, на которой он работает. Причем платформа — это не только и не столько ось, сколько набор библиотек и инструментов, созданных для этого языка.
Ты что, серьезно думаешь, что типизация поможет тебе портировать прогу с (к примеру) C# на оберон? Переписать полностью, и скорее всего перепроектировать — единственный возможный вариант. То есть, на самом деле, невозможный.

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

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

Д>Какие еще наведенные эффекты могут быть от замены lock(this) на lock(syncObject)?

Чужой исходный код или отдали что-то на аутсорс, а исходников нет, а делать надо.

Д>Вот это конкретное решение, в этом конкретном случае? Ты проверял?

Вот конкретное решение я много раз проверял в жизни. Оно не работает во многих случаях. Для того чтобы оно работало должен быть довольно жестко организованный процесс разработки, а это много чего значит. Далеко не всегда это так, ваш совет увольнятся с работы (и идти например на в два раза меньшую зарплату) больше похож на утопию. Вы ВЕРИТЕ в организационные методы. Я принципиально в них НЕ ВЕРЮ.

Д>>>скорее — не может быть достаточно важной причиной. Тем более что надо не только менять средство разработки, но еще и переписывать весь код.

SM>>Может при прочих равных. Вы ведь не против типизации? Или все таки против?

А где вы видели утверждение о том, что Я предлагаю все переписать на Обероне? Например почему не начать новый проект на Обероне, если он содержит необходимые нам библиотеки? Я лишь утверждаю, что при прочих равных это может быть решаюшим доводом в пользу выбора платформы. Кто сказал, что издержки на обучения будут выше издержек на правку багов или наладки нормального процесса разработки?

Сравнение с типизацией не случайно. Типизация позволяет избежать ряда ошибок. Обсуждаемая особенность позволяет избежать ряда ошибок, при этом не создавая дополнительных проблем.

Да кстати я так и не услышал ответа на свой вопрос по поводу типизации.

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

Д>>Какие еще наведенные эффекты могут быть от замены lock(this) на lock(syncObject)?

SM>Чужой исходный код или отдали что-то на аутсорс, а исходников нет, а делать надо.

А что вообще ты собрался делать, если нет исходников?
И все-таки, какие вообще наведенные эффекты могут быть от такой замены в принципе?

Д>>Вот это конкретное решение, в этом конкретном случае? Ты проверял?

SM>Вот конкретное решение я много раз проверял в жизни. Оно не работает во многих случаях. Для того чтобы оно работало должен быть довольно жестко организованный процесс разработки, а это много чего значит. Далеко не всегда это так, ваш совет увольнятся с работы (и идти например на в два раза меньшую зарплату) больше похож на утопию. Вы ВЕРИТЕ в организационные методы. Я принципиально в них НЕ ВЕРЮ.

Я не верю в организационные методы, я просто их иногда использую. А еще я не верю в незыблемые принципы, потому что это уже из области религии. Одни и те же методы могут и работать, и не работать, в зависимости от обстоятельств.
Какие проблемы могут быть вот в данном конкретном случае? И вообще, почему обязательно в два раза меньшую зарплату? У меня обычно бывает наоборот

SM>А где вы видели утверждение о том, что Я предлагаю все переписать на Обероне? Например почему не начать новый проект на Обероне, если он содержит необходимые нам библиотеки? Я лишь утверждаю, что при прочих равных это может быть решаюшим доводом в пользу выбора платформы.

"прочих равных" здесь нет и быть не может. Единственной причиной для выбора оберона могут быть религиозные соображения, потому что по всем реальным характеристикам он сливает другим технологиям. Для embedded есть Symbian. Для параллельных систем — Erlang. И так далее.

SM>Сравнение с типизацией не случайно. Типизация позволяет избежать ряда ошибок. Обсуждаемая особенность позволяет избежать ряда ошибок, при этом не создавая дополнительных проблем.

А какой "ряд ошибок" может быть по причинам, которые мы сейчас рассматриваем?

SM>Да кстати я так и не услышал ответа на свой вопрос по поводу типизации.

Ты хочешь об этом поговорить? Если действительно очень хочешь, то я отвечу — сильная статическая типизация рулит в большинстве случаев.

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

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

Извините, конечно, что вмешиваюсь в ваш спор, но, вроде, Ваш оппонент ничего про Oberon и не утверждал. Это во-первых, так что Ваш выпад против Oberon неуместен и непонятен. Во-вторых, коль скоро этот выпад Вами всё-таки был сделан, то со своей стороны, замечу, что Вы сказали неправду. По реальным характеристикам, например, Blackbox находится где-то на уровне технологий .Net & Java. На разных оберонах написан ряд операционных систем, в том числе операционных систем реального времени, в том числе для встраиваемых аппаратных систем. Кроме того, ведущие академические проекты осуществлялись и осуществляются именно на оберонах. Обероны успешно используются и в ряде коммерческих организаций. А на Modula (предшественнике Oberon) программируются космические спутники.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Извините, конечно, что вмешиваюсь в ваш спор, но, вроде, Ваш оппонент ничего про Oberon и не утверждал. Это во-первых, так что Ваш выпад против Oberon неуместен и непонятен.

Поскольку в данной ветке мы обсуждали фичу именно оберона, то меня очень удивляет твое утверждение, что мое заявление о нем здесь неуместно.

СГ> Во-вторых, коль скоро этот выпад Вами всё-таки был сделан, то со своей стороны, замечу, что Вы сказали неправду. По реальным характеристикам, например, Blackbox находится где-то на уровне технологий .Net & Java.

Список этих реальных характеристик — в студию! Желательно в виде таблицы с плюсиками и минусиками. Только реальных фич, а не типа "в комментарии можно вставлять картинки"

СГ>На разных оберонах написан ряд операционных систем, в том числе операционных систем реального времени, в том числе для встраиваемых аппаратных систем. Кроме того, ведущие академические проекты осуществлялись и осуществляются именно на оберонах. Обероны успешно используются и в ряде коммерческих организаций. А на Modula (предшественнике Oberon) программируются космические спутники.

да, как же много зависит от правильной постановки высказывания
Мне даже лень снова посылать тебя в googlewars... может быть, проще согласиться? (в глубоком раздумье)

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

ГВ>Ну, скажем так. К труднообнаружимым ошибкам (ТОО) обычно приводит хаотичный процесс разработки. Сами по себе особености того или иного языка влияют на возникновение ошибок весьма косвенно.

Думается, между языком и процессом разработки есть связь.
IMHO, язык создается в расчете на определенный характер процесса разработки, и именно поэтому в Си так много "лазеек" (loopholes), а в Обероне — мало.

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

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

Д>>>Какие еще наведенные эффекты могут быть от замены lock(this) на lock(syncObject)?

SM>>Чужой исходный код или отдали что-то на аутсорс, а исходников нет, а делать надо.

Д>А что вообще ты собрался делать, если нет исходников?
Д>И все-таки, какие вообще наведенные эффекты могут быть от такой замены в принципе?

Скажите а сборки в .NET уже отменили? Рассмотрим ситуацию у нас есть пакет основной, который делает другая организация. И есть два пакета, которые делаются на его основе. Мы делаем один пакет, а другая фирма делает другой пакет. Теперь рассмотрим ситуацию, что у нас что-то не работает. Количество возможных причин почему у нас не работает, при использовании активных объектов падает или увеличивается?

Я полагаю, что падает, поскольку исключена потенциально опасная конструкция. Я не прав?

SM>>Вот конкретное решение я много раз проверял в жизни. Оно не работает во многих случаях. Для того чтобы оно работало должен быть довольно жестко организованный процесс разработки, а это много чего значит. Далеко не всегда это так, ваш совет увольнятся с работы (и идти например на в два раза меньшую зарплату) больше похож на утопию. Вы ВЕРИТЕ в организационные методы. Я принципиально в них НЕ ВЕРЮ.


Д>Я не верю в организационные методы, я просто их иногда использую. А еще я не верю в незыблемые принципы, потому что это уже из области религии. Одни и те же методы могут и работать, и не работать, в зависимости от обстоятельств.
Д>Какие проблемы могут быть вот в данном конкретном случае? И вообще, почему обязательно в два раза меньшую зарплату? У меня обычно бывает наоборот

К сожалению то, какие организационные методы использовать обычно решают не программисты, надеюсь не надо объяснять как сложно перестраивать уже существующий процесс разработки? У вас дети жена есть? Это пока вы свободный человек и у вас есть достаточно большие сбережения вы можете себе позволить менять работу тогда, когда вам удобно. А вот в остальных случаях все не так хорошо. И рецепт валить очень часто не работает.

SM>>А где вы видели утверждение о том, что Я предлагаю все переписать на Обероне? Например почему не начать новый проект на Обероне, если он содержит необходимые нам библиотеки? Я лишь утверждаю, что при прочих равных это может быть решаюшим доводом в пользу выбора платформы.

Д>"прочих равных" здесь нет и быть не может. Единственной причиной для выбора оберона могут быть религиозные соображения, потому что по всем реальным характеристикам он сливает другим технологиям. Для embedded есть Symbian. Для параллельных систем — Erlang. И так далее.

Ну походу случай клинический. Скажите мы собираемся выпустить новый процессор что делать? И сколько это стоит? Неужели вы не видите какя выстраивается пирамида с Java и .Net? И где в этой пирамиде вершина?

Тему пирамиды я готов с вами обсудить.

А вот если вдруг IBM возьмет и напишет систему использующую активные объекты, что тогда? Не я понимаю, что это очень очень мало вероятно, но все таки.

Д>Ты хочешь об этом поговорить? Если действительно очень хочешь, то я отвечу — сильная статическая типизация рулит в большинстве случаев.

Нет я проверяю вменяемость того с кем разговариваю. Если человек не признает типизацию, то ИМХО он не вменяемый.