Re[54]: Нужна ли Оберон-ОС защита памяти?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.02.05 10:26
Оценка:
Здравствуйте, Кодт, Вы писали:

СГ>>Так что, извините, но самого обычного массива массивов в Си/Си++ нет.


К>Беспочвенный шовинизм.


Ничего подобного.

Oberon
Вариант первый:
TYPE
  ArrayOfArray = ARRAY OF ARRAY OF INTEGER;

Вариант второй:
TYPE
  ArrayOfInteger = ARRAY OF INTEGER;
  ArrayOfArray = ARRAY OF ArrayOfInteger;






Теперь посмотрим как это будет в Си/Си++.
Может быть так:
    typedef int ArrayOfArray[][]; // Ошибка компиляции

опаньки, не компилируется. Черт побери, а может быть вот так будет правильно:
    typedef int Array[];
    typedef Array ArrayOfArray[]; // Ошибка компиляции

опаньки, опять не компилируется!

Visual C++ Concepts: Building a C/C++ Program
Compiler Error C2087'identifier' : missing subscript

The definition of an array with multiple subscripts is missing a subscript value for a dimension higher than one. The following sample generates C2087:

// C2087.cpp
int main()
{
char a[10][]; // C2087
char b[4][5]; // OK
}

Re[8]: Нужна ли Оберон-ОС защита памяти?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.02.05 10:48
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Сказки только не надо рассказывать — это делается элементарно без всяких

S>оберонов. EnterCriticalSection/LeaveCriticalSection (или, по вкусу —
S>boost::mutex/boost::mutex::scoped_lock) на замену EXCLUSIVE подойдут вполне.
S>А AWAIT может быть реализован хоть на бесконечном цикле со Sleep(0) внутри,
S>хоть на WaitForSingleObject, хоть на любом другом удобном для конкретного
S>случая примитиве.


Естественно, что в не ОО системах типа UNIX/Windows процессы/потоки которых есть надстройка над ядром ОСи, для синхронизации используются объекты самой (нижележащей) ОСи.

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

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

Про элементарность:
Для описания синхронизации активных объектов используется всего два слова EXCLUSIVE и AWAIT — вот уж поистине элементарно, а Вы что назвали элементарным — сонмище всяких: EnterCriticalSection/LeaveCriticalSection, Mutex, Sleep, WaitForSingleObject и т.д.


Примеры реализации типичных "параллельных паттернов" посредством EXCLUSIVE и AWAIT:

http://bluebottle.ethz.ch/languagereport/node8.html
Readers and Writers
Signals
Re-entrant Locks
Binary and Generic Semaphores
Barrier
Bounded Buffer

http://bluebottle.ethz.ch/languagereport/node9.html
Dining Philosophers
Sieve of Eratosthenes

http://bluebottle.ethz.ch/languagereport/index.html
Active Oberon Language Report
Re[9]: Нужна ли Оберон-ОС защита памяти?
От: Sergey Россия  
Дата: 10.02.05 11:40
Оценка:
Hello, Сергей!
You wrote on Thu, 10 Feb 2005 10:48:41 GMT:

СГ> А вот активные объекты существуют без операционной системы прямо на

СГ> голом железе (точнее поверх рантайм системы языка программирования),
СГ> там наоборот — операционная система состоит из них находится выше.

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

СГ> Следовательно ничем принадлежащим ОСи активные объекты для своей

СГ> синхронизации пользоваться не могут.
Да пусть не пользуются. В MFC-то примитивами синхронизации никто
пользоваться не запрещает.

СГ> Про элементарность:

СГ> Для описания синхронизации активных объектов используется всего два
СГ> слова EXCLUSIVE и AWAIT — вот уж поистине элементарно, а
СГ> Вы что назвали элементарным — сонмище всяких:
СГ> EnterCriticalSection/LeaveCriticalSection, Mutex, Sleep,
СГ> WaitForSingleObject и т.д.

Сонмище — это потому что выбор есть
На самом деле твоя комбинация из EXCLUSIVE и AWAIT на С++ может выглядеть,
например, так:

lock lk(monitor);

while (buffered == 0)

    buffer_not_empty.wait(lk);



ну а весь bounded buffer на C++ может выглядеть, например, так:

class bounded_buffer : private boost::noncopyable
{
public:
    typedef boost::mutex::scoped_lock lock;

    bounded_buffer(int n) : begin(0), end(0), buffered(0), circular_buf(n) 
{ }

    void send (int m) {
        lock lk(monitor);
        while (buffered == circular_buf.size())
            buffer_not_full.wait(lk);
        circular_buf[end] = m;
        end = (end+1) % circular_buf.size();
        ++buffered;
        buffer_not_empty.notify_one();
    }
    int receive() {
        lock lk(monitor);
        while (buffered == 0)
            buffer_not_empty.wait(lk);
        int i = circular_buf[begin];
        begin = (begin+1) % circular_buf.size();
        --buffered;
        buffer_not_full.notify_one();
        return i;
    }

private:
    int begin, end, buffered;
    std::vector<int> circular_buf;
    boost::condition buffer_not_full, buffer_not_empty;
    boost::mutex monitor;
};


СГ> Примеры реализации типичных "параллельных паттернов" посредством

СГ> EXCLUSIVE и AWAIT:

Я вашей мовы паскальской не разумею

With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[36]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 10.02.05 12:20
Оценка:
Здравствуйте, Privalov, Вы писали:

AVC>>В данном случае источник информации — Стефан Метцелер, субъект весьма интересный.

AVC>>С ним можно не соглашаться, но почитать его опусы стоит (imho).
AVC>>Хотя бы потому, что его программистская производительность на порядок превосходит уровень "продвинутого" С++нутого программиста.
AVC>>Лично мне наиболее интересной кажется статейка
AVC>>http://www.amadeus-3.com/main_files/FlawsOfCPP.php
AVC>>но можно почитать и
AVC>>http://www.amadeus-3.com/main_files/oberon2vsCPP.php

P>Статьи как статьи. С ними можно соглашаться, можно спорить.


Именно это я и сказал.

P>На самом деле сравнение языков программирования — очень неблагодарный процесс (хотя, несомненно, нужный). Если, к тому же, он выполняется одним человеком, он всегда слишком субъективен, потому что в силу тех или иных причин человек всегда отдает предпочтение одному из объектов сравнения (в данном случае — языку программирования).


Полностью согласен.
Просто существуют достаточно интересные случаи, когда человек вдруг отходит от языка "мэйнстрима", и начинает пользоваться другим, менее известным и поддерживаемым "промышленностью" языком.
При этом добивается значительных результатов (как Метцелер).
Конечно, Оберон, не единственный язык, ведущий иногда к таким результатам.
Не так давно я наткнулся где-то на статейку Пола Грехема, в которой он поведал, что самое успешные американские коммерческие Web-сайты были созданы на... Лиспе.

P>Без всякой иронии — как измерялась производительность этого парня? Вопрос об измерении производительности программиста поднимается не реже, чем Oberon vs. C++, поэтому интересно знать, какие критерии использовались в данном случае.


Ну, например:

Unless you know other programmers who manage to write a complete OO Framework such as Amadeus-3 in their "spare time", while developing about 20 serious applications for major, multi-national companies (Du Pont de Nemours, Royal Bank of Canada, HP etc.) over a period of 8 years, this should convince you that Oberon-2 programming is indeed as efficient as claimed on this site.


P>А может, все недостатки C++ происходят оттого, что проектировался он не в академической организации, а в коммерческой структуре? Подход к разработке в коммерческих и академических организациях сильно различается. В исследовательской лаборатории можно одним махом выбросить старую платформу и перейти на новую. Вирт не раз так делал. Например, он призывал всех отказаться от Паскаля в пользу Модулы-2. Но в жизни, в жестких условиях временных, бюджетных и прочих ограничений, подобное, как правило, невозможно. Отсюда требование — сохранить совместимость со старым работающим софтом. А дальше так: ввели в язык, например, перегрузку, и появилось ключевое слово overload. И сохранялось оно в C++ годы. Потому что кто-то где-то его использовал. Так что проблема избавления от анахронизмов — гораздо более сложная, чем изобретение новых возможностей.


AVC>>Главное: инструмент перестал умещаться в руке.

P>Согласен. Есть, впрочем, надежда, что C++ не повторит путь PL/1.

У меня — уже нет.
Отсюда и недовольство.
А ведь был неплохой инструмент.

Что же касается "академизма" Вирта и "давления индустрии" на Страуструпа, то, ИМХО, это все — байки.
Я знаю несколько программ — компиляторов, операционных систем, встроенных систем и т.д., написанных лично Виртом.
И не знаю ни одного серьезного приложения, написанного Страуструпом.
Также не думаю, что на Страуструпа сильно давили в Bell Laboratories.
Ведь там, кроме Си, было создано множество языков.

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

Хоар
Re[51]: Нужна ли Оберон-ОС защита памяти?
От: Cyberax Марс  
Дата: 10.02.05 12:37
Оценка:
AVC пишет:

> C>А _КАКОЙ_ массив массивов? Их несколько вариантов может быть, причем

> для
> C>разных условий лучше подходят разные варианты.
> Я не против других вариантов.
> Но Вы все же лукавите. Я же ясно написал — массив *массивов*, причем
> мы договорились называть массивом *базовую конструкцию языка*. Так что
> вариант, конечно, *в данном случае* только один.

Да?

std::vector<std::vector<something> > - вот и массив массивов.

или так:
int arr[xdim*ydim];

и даже вот так:
template<class T> struct MatrixEntry
{
    MatrixEntry<T> *nextInRow, *prevInRow, *nextInColumn, *prevInColumn;
    T val;
};


>>> Т.к. массив — базовая конструкция, то язык должен это позволять.

>>> А Си++ — не позволяет.
> C>boost::multi_array, и ваши волосы будут мягкими и шелковистыми...
> Ах, увы... впрочем, что это я?
> А что, массива — *просто мас-си-ва* — сегодня в продаже нет?

А зачем он нужен "просто массив"?

> C>А вот сделать разреженную матрицу на Обероне красиво не получится.

> C>Вместо оператора индекса будет всякие функции типа GetElement().
> Да, блин, что-то некрасиво получается.
> GetElement(), уродство какое-то...

Да, уродство.

>>> Если есть обход, то это не сильная типизация.

> C>Она сильная, но отключаемая
> Что-то мне это напоминает ежика:
> Сильный-то я сильный. Но легкий.

Примерно так.

>>> А когда выйдет новый стандарт?

> C>Недавно, кажется вышел. Добавили стандартный ABI.
> Тут я "зарапортовался". Получилась двусмысленность. Как будто я с
> нетерпением ожидаю еще одного стандарта Си++, от которого мои
> "шелковистые волосы" прорастут уж в совсем неожиданных местах.
> Я хотел сказать, что *пока* еще Си++ удается усидеть на нескольких
> стульях.

В новом стандарте почти нет измений, просто стандартизовали ABI.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[55]: Нужна ли Оберон-ОС защита памяти?
От: Cyberax Марс  
Дата: 10.02.05 13:02
Оценка:
AVC пишет:

> К>Ещё раз для тех, кто в Обероне: указатель на массив и указатель на

> одиночный элемент в С/С++ неразличимы.
> Для тех, кто в Си++. (Хотя пока и вынужденно кратко.)
> 1) Помедитируйте над Вашим утверждением в свете планов Страуструпа о
> введении GC в Си++.
> "Шелковистые волосы" на голове не шевелятся?

Дык, уже. MC++, аднака.

> Как всегда — "повешено" на программиста.


Поэтому и надо boost::array использовать

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[7]: Нужна ли Оберон-ОС защита памяти?
От: Cyberax Марс  
Дата: 10.02.05 13:06
Оценка: +1
Сергей Губанов пишет:

> Подсказка.

> В рантайм системе Aos инструкция AWAIT просто ставит активность
> (активный объект) в очередь ожидания выполнения условия, так что
> лишнее процессорное время не расходуется. Активных объектов
> одновременно может быть десятки тысяч! Представьте что будет (в случае
> MFC), кода 50'000 потоков будут каждый в своем бесконечном цикле AWAIT
> дожидаться чего-нибудь. Вроде ничего не происходит, все просто чего-то
> ждут, а процессор загружен на 100%.

RTFM про spinlock'и и мьютексы, а так же про их реализацию в современных
ОС. Еще рекомендую почитать про O(1) планировщики.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[9]: Нужна ли Оберон-ОС защита памяти?
От: Cyberax Марс  
Дата: 10.02.05 13:15
Оценка:
Сергей Губанов пишет:

> Про элементарность:

> Для описания синхронизации активных объектов используется всего два
> слова *EXCLUSIVE* и *AWAIT* — вот уж поистине элементарно, а Вы что
> назвали элементарным — сонмище всяких:
> EnterCriticalSection/LeaveCriticalSection, Mutex, Sleep,
> WaitForSingleObject и т.д.

И вот так в Обероне всегда... То что придумал Вирт — единственный и
правильный путь к счастью.

Мьютексы и критические секции отличаются, например, скоростью работы и
механизмом блокировки. А WFSO — это просто готовая реализация монитора.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[10]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 10.02.05 13:32
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Сергей Губанов пишет:

>> Про элементарность:
>> Для описания синхронизации активных объектов используется всего два
>> слова *EXCLUSIVE* и *AWAIT* — вот уж поистине элементарно, а Вы что
>> назвали элементарным — сонмище всяких:
>> EnterCriticalSection/LeaveCriticalSection, Mutex, Sleep,
>> WaitForSingleObject и т.д.
C>И вот так в Обероне всегда... То что придумал Вирт — единственный и
C>правильный путь к счастью.
C>Мьютексы и критические секции отличаются, например, скоростью работы и
C>механизмом блокировки. А WFSO — это просто готовая реализация монитора.

Все это не по делу.
AWAIT придумал не Вирт, а Бринч Хансен.
Это высокоуровневая и очень простая в использовании конструкция, существенно проще для программиста, чем сигналы, мониторы, критические секции.
Поэтому она часто используется в литературе, посвященной многопоточности. (Например, в книге Эндрюса.)
Что может быть проще в использовании, чем, например, упомянутое Сергеем
AWAIT(n # 0);
?
Но до последнего времени не было эффективной реализации AWAIT.
А Питер Мюллер, похоже, сумел сформулировать условия, при которых AWAIT может быть реализован эффективно. По крайней мере, это утверждается в описании Активного Оберона:

The AWAIT statement was proposed and investigated by Brinch Hansen [3]
who showed its conceptual simplicity and elegance, but also thought it would
be impossible to implement it efficiently. We repropose it in Active Oberon,
with the conviction that it is a real improvement compared with signals and
semaphores, because of the unification and clarity it brings; it becomes particularly
obvious in an object-oriented programming style, where signals and
semaphores are completely inappropriate because of their unstructured use, as
they can be inserted arbitrarily in a program. Pieter Muller’s thesis [21] proves,
that with the appropriate restrictions, AWAIT can be implemented efficiently.
The language Ada 95 [14] has also a construct called barriers, which is se-mantically
very similar to Active Oberon’s AWAIT, although with a coarser
procedure-width granularity.

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

Хоар
Re[52]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 10.02.05 13:53
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> Но Вы все же лукавите. Я же ясно написал — массив *массивов*, причем

>> мы договорились называть массивом *базовую конструкцию языка*. Так что
>> вариант, конечно, *в данном случае* только один.
C>Да?
C>
C>std::vector<std::vector<something> > - вот и массив массивов.
C>

C>или так:
C>
C>int arr[xdim*ydim];
C>

C>и даже вот так:
C>
C>template<class T> struct MatrixEntry
C>{
C>    MatrixEntry<T> *nextInRow, *prevInRow, *nextInColumn, *prevInColumn;
C>    T val;
C>};
C>


А просто
void foo(float a[][]);
нельзя?
Или это тоже... того... некрасиво?

C>А зачем он нужен "просто массив"?


Т.е. я еще должен Вам объяснять, как используются массивы?
Увольте.
Лучше прочтите на досуге какой-нибудь учебник программирования для начинающих.

>> C>А вот сделать разреженную матрицу на Обероне красиво не получится.

>> C>Вместо оператора индекса будет всякие функции типа GetElement().
>> Да, блин, что-то некрасиво получается.
>> GetElement(), уродство какое-то...
C>Да, уродство.

Особенно если сравнивать с классическими образцами красоты:
std::vector<std::vector<something> > - вот и массив массивов.

int arr[xdim*ydim];



Вообще, наша с Вами дискуссия вырождается в заурядный флейм.
(Без обид и выяснения, кто прав, а кто виноват. )
Наверное, нужна творческая пауза.

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

Хоар
Re[11]: Нужна ли Оберон-ОС защита памяти?
От: Cyberax Марс  
Дата: 10.02.05 13:54
Оценка:
AVC пишет:

> C>И вот так в Обероне всегда... То что придумал Вирт — единственный и

> C>правильный путь к счастью.
> C>Мьютексы и критические секции отличаются, например, скоростью работы и
> C>механизмом блокировки. А WFSO — это просто готовая реализация монитора.
> Все это не по делу.
> AWAIT придумал не Вирт, а Бринч Хансен.

В язык-то добавил ее Вирт.

> Это высокоуровневая и очень простая в использовании конструкция,

> существенно проще для программиста, чем сигналы, мониторы, критические
> секции.

Да? Мне, например, так не кажется. Кстати, а как у вас там цепную
блокировку использовать (для связных списков, например)?

> Поэтому она часто используется в литературе, посвященной

> многопоточности. (Например, в книге Эндрюса.)
> Что может быть проще в использовании, чем, например, упомянутое Сергеем
>
>AWAIT(n # 0);
>
> ?

WaitForSingleObject в WinAPI, например А если серьезно, то аналог
AWAIT'а есть в boost'е — называется "condition".

> The language Ada 95 [14] has also a construct called barriers, which

> is se-mantically
> very similar to Active Oberon’s AWAIT, although with a coarser
> procedure-width granularity.

Надо на досуге наваять подобное на boost.threads + boost.phoenix.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[53]: Нужна ли Оберон-ОС защита памяти?
От: Cyberax Марс  
Дата: 10.02.05 13:58
Оценка:
AVC пишет:

> А просто

>
>void foo(float a[][]);
>
> нельзя?

Нет, нельзя. Потому как не "просто" — возможны несколько неравноценных
вариантов.

> C>А зачем он нужен "просто массив"?

> Т.е. я еще должен Вам объяснять, как используются массивы?

Я имею в виду "просто массив". Чем класс с интерфейсом массива не угодил?

Кстати, а в Oberon'е можно делать срезы массивов, проекции и т.п.?

>>> GetElement(), уродство какое-то...

> C>Да, уродство.
> Особенно если сравнивать с классическими образцами красоты:
>
>std::vector<std::vector<something> > — вот и массив массивов.
>
>
>int arr[xdim*ydim];
>
>
>
Просто объявления. А доступ будет выглядеть так:
1) a[0][2]=...;
2) arr[xdim*y+x]=...;

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[55]: Нужна ли Оберон-ОС защита памяти?
От: Павел Кузнецов  
Дата: 10.02.05 14:01
Оценка: +1
AVC,

> Т.к. в Си++ нельзя написать
void foo(float a[][]);

> то массива массивов (по крайней мере, в этом смысле) в Си++ нет.

Даже если бы было можно, то означало бы это то же самое, что и
void foo(float** a);

В общем, к гадалке не ходи: есть встроенные массивы массивов в C++, нет встроенных массивов массивов в C++ — науке не известно Даже если принять точку зрения, что встроенные массивы массивов в C++ есть, то надо будет сразу делать кучу оговорок, что массивы в языках C и C++ вообще на положении бедных родственников (not a first class citizens). Что мне лично при использовании данных языков не нравится, но вероятность исправления данной ситуации, пожалуй, устремлена к 0 из-за соображений обратной совместимости.

С другой стороны, имхо, верным будет и утверждение, что в C++ это компенсируется развитыми возможностями создания своих типов, по использованию, фактически, не отличающихся от встроенных.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[37]: Нужна ли Оберон-ОС защита памяти?
От: Privalov  
Дата: 10.02.05 14:12
Оценка:
Здравствуйте, AVC, Вы писали:

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

AVC>При этом добивается значительных результатов (как Метцелер).
AVC>Конечно, Оберон, не единственный язык, ведущий иногда к таким результатам.
AVC>Не так давно я наткнулся где-то на статейку Пола Грехема, в которой он поведал, что самое успешные американские коммерческие Web-сайты были созданы на... Лиспе.

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

AVC>>>Главное: инструмент перестал умещаться в руке.

P>>Согласен. Есть, впрочем, надежда, что C++ не повторит путь PL/1.

AVC>У меня — уже нет. :(

AVC>Отсюда и недовольство.
AVC>А ведь был неплохой инструмент.

AVC>Что же касается "академизма" Вирта и "давления индустрии" на Страуструпа, то, ИМХО, это все — байки.

AVC>Я знаю несколько программ — компиляторов, операционных систем, встроенных систем и т.д., написанных лично Виртом.
AVC>И не знаю ни одного серьезного приложения, написанного Страуструпом.
AVC>Также не думаю, что на Страуструпа сильно давили в Bell Laboratories.
AVC>Ведь там, кроме Си, было создано множество языков.

Как утверждает здесь сам Страуструп, компилятор C++ реализован им самим. Думаю, что это достаточно серьезный проект.

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

Вирт стремится создать идеальную систему. Здесь можно прочитать о проектах, над которыми он работал. Немногие из них дошли до нас в первозданном виде. (В тот год, когда я стал студентом, обучение программированию стало вестись на базе Фортрана, до этого оно велось на базе алгола. Не думаю, что это наш курс повлиял).

Страуструп, напротив, практик. Его место работы, можно сказать, КБ или отраслевой НИИ. Основная задача таких организаций — воплощение в жизнь теорий, создаваемых академиками. Где-то на этом форуме уже обсуждалась подобная тема.

Работа Вирта дала материал для размышления многим, в том числе Страуструпу. Однако, прагматизм последнего (вольный или невольный), несомненно, сыграл свою роль в том, что C++ распространен гораздо шире, чем любой из проектов Вирта.
Re[12]: Нужна ли Оберон-ОС защита памяти?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.02.05 14:14
Оценка:
Здравствуйте, Cyberax, Вы писали:

AVC> AWAIT придумал не Вирт, а Бринч Хансен.


C>В язык-то добавил ее Вирт.


Опять мимо. Язык Active Oberon создали Юрг Гуткнехт, A. R. Disteli и Patrik Reali. Реализовал систему Aos Питер Мюллер. Эмуляцией Aos-а под Windows занимается, например, Felix Friedrich ETH Win Aos Oberon System.
Re[8]: Нужна ли Оберон-ОС защита памяти?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.02.05 14:18
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>RTFM про spinlock'и и мьютексы, а так же про их реализацию в современных

C>ОС. Еще рекомендую почитать про O(1) планировщики.

spinlock'и и мьютексы — это объекты операционной системы, а Вы попробуйте обойтись без объектов ОСи — средствами только самого языка программирования. Представьте себе что хотите написать программу которая должна работать на голом железе (точнее — в рантайм системе языка программирования).
Re[54]: Нужна ли Оберон-ОС защита памяти?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.02.05 14:27
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Кстати, а в Oberon'е можно делать срезы массивов, проекции и т.п.?


Если есть процедура

PROCEDURE Calculate(VAR vector: ARRAY OF REAL);


то в нее можно можно передать matrix[n], где matrix — это ARRAY OF ARRAY OF REAL.

И так далее, если есть процедура на вход которой подается ARRAY OF...ARRAY OF, то в нее можно засунуть "срез"

{ARRAY OF ... ARRAY OF ARRAY OF ...ARRAY OF ...}{ARRAY OF ...ARRAY OF ...}

оторвав у этой "пирамиды" макушку, т.е. лишние размерности

Calculate3D(matrix5D[m, n]);
3 = 5 — 2

Calculate4D(matrix7D[m, n, k]);
4 = 7 — 3
Re[6]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 10.02.05 14:34
Оценка:
Здравствуйте, Кодт, Вы писали:

К>>>Во-первых, вылететь из очереди планировщика можно тремя способами:

К>>>- из running в waiting
К>>>- из running в suspended
К>>>- из ready в suspended
AVC>>ИМХО, это зависит от ОС.
AVC>>Может быть три способа, а может быть тридцать три.
К>Интересно, это какие же тридцать три, если всего есть 5 принципиально разных состояний (выполняется, готов, усыплён, ждёт, завершён).

Так это какими абстракциями пользоваться.
Я, например, вижу только три состояния:
1) текущий процесс (running по Вашему);
2) процесс в очереди исполнения (ready);
3) ждущий какого-нибудь внешнего события (waiting).
Конечно, для последнего варианта можно насчитать множество разновидностей.
Но процесс все равно находится в состоянии ожидания того светлого времени, когда его "разбудит" диспетчер.

AVC>>Для обеспечения сохранности инвариантов существуют мониторы. (Или другие средства синхронизации.)

AVC>>Если система поддерживает мониторы, то неясно, почему могут быть нарушены (системные) инварианты.
К>Монитор, я так понимаю, не предполагает исключительное и непрерываемое исполнение программы? Или предполагает?!

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

К>- сборщик мусора знает о мониторе и честно ждёт (или просто обходит стороной) заблокированные данные; достаточно теперь зависнуть в мониторе (например, на взаимоблокировке или банальном бесконечном цикле) — и привет


Если мониторы, связанные с управлением памятью, входят в состав ядра ОС, то зависание такого монитора равносильно зависанию ядра.
А уж если ядро зависло — ничего не попишешь...

К>- сборщик мусора не знает о мониторах и нагло копается в заблокированных данных, в том числе — на полудохлых


Только, если существует единственный процесс.

К>- все операции, влияющие на граф зависимостей (инициализация и присваивание указателей) атомарны — это достигается или кооперативной многозадачностью, или накладными расходами; сборщик мусора имеет право убивать заблокированный монитор.


Зачастую вполне приемлимый вариант.
Пара лишних операций на присваивание указателей все же эффективнее переключения контекста.

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

AVC>>Здесь нет ничего специфичного для ОС Оберон.
AVC>>На что, кстати, уже обращалось внимание.
К>А я и не говорю про Оберон. Просто в системах, где потоки — это низкий уровень, команду kill или TerminateThread применяют только от безысходности или по разгильдяйству. А если система сама будет решать, когда ей прибивать якобы заторможенный активный объект — будет много увлекательных приключений.

О, искусственный интеллект!

К>>>То ли этот объект зацеплен за очередь к ресурсу, то ли его оттуда можно смело выдёргивать.

AVC>>Откуда?
AVC>>Вопрос неясен.
К>Откуда: из очереди к ресурсу.

Тогда объект все же зацеплен за очередь к ресурсу.
В чем дилемма?

AVC>>А как он это сделает в условиях нескольких адресных пространств?

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

То же самое, ИМХО, возможно и при едином адресном пространстве.

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

Хоар
Re[52]: Нужна ли Оберон-ОС защита памяти?
От: Павел Кузнецов  
Дата: 10.02.05 14:41
Оценка:
Cyberax,

>>>> А когда выйдет новый стандарт?


>> C>Недавно, кажется вышел. Добавили стандартный ABI.


>> <...>


> В новом стандарте почти нет измений, просто стандартизовали ABI.


О каком стандарте идет речь? В 2003 ABI не стандартизировали, просто исправили ошибки 1998-го.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[9]: Нужна ли Оберон-ОС защита памяти?
От: Cyberax Марс  
Дата: 10.02.05 14:42
Оценка:
Сергей Губанов пишет:

> C>RTFM про spinlock'и и мьютексы, а так же про их реализацию в

> современных
> C>ОС. Еще рекомендую почитать про O(1) планировщики.
> spinlock'и и мьютексы — это объекты операционной системы, а Вы
> попробуйте обойтись без объектов ОСи — средствами только самого языка
> программирования.

Поправка: объектом операционный системы является только мьютекс.
Критические секции работает исключительно в пользовательском коде
(смотри документацию на *InterlockedCompareExchange* в MSDN),
соответственно крит. секции валидны только в пределах текующего процесса.

> Представьте себе что хотите написать программу которая должна работать

> на голом железе (точнее — в рантайм системе языка программирования).

И что? Realtime-программирование не значит отсутствие ОС.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.