Re[3]: Оберон круче всех!
От: uncommon Ниоткуда  
Дата: 28.08.12 01:07
Оценка: +1 :))
Здравствуйте, vdimas, Вы писали:

V>Ничего не перепутал? Сможешь показать, в каких популярных императивных языках оно есть?


Кстати, насчет того, что в Обероне есть. Вот здесь адепты Оберона обсуждают как бы им на Обероне зафигачить интерфейсы. Язык на прямую их не поддерживает. Объекты есть, а интерфейсов нет. Полиморфизм реализуется ручками, через задницу, со всему причитающимися граблями вроде ручной инициализации объектов и заполнения виртуальных таблиц. А вы, алгебраические типы, алгебраические типы!
Re[2]: Оберон круче всех!
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.09.12 12:05
Оценка:
Здравствуйте, Kernan, Вы писали:

K>Сергей Губанов, вы реинкарнировали в vdimas?


Вижу меня тут помнят и любят

Я не реинкарнировал в vdimas.

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

В соседнем посте Алексей описал плачевную ситуацию с оберонкоре: http://rsdn.ru/forum/philosophy/4842898.1.aspx
Автор: valexey_
Дата: 05.08.12
Re[3]: Оберон круче всех!
От: AlexRK  
Дата: 10.09.12 12:13
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


А за что забанили, если не секрет?
Re[4]: Оберон круче всех!
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 10.09.12 14:19
Оценка: 29 (3)
Здравствуйте, AlexRK, Вы писали:

ARK>А за что забанили, если не секрет?


За "дать в морду Ткачёву" (который info21). Ткачёв троллил все обсуждения, которые по его мнению могли причинить вред его проекту "Информатика 21". Каждый раз по его вине начинался срач бессмысленный и беспощадный. Потом загаженная Ткачёвым ветка исчезала из свободного доступа (или совсем) под предлогом... загаженности. Ткачёву за это никогда ничего не было. После того как эта схема повторилась несколько раз я инициировал обсуждение как наказать Ткачёва. Ткачёв опять устроил срач. Ему за это опять ничего не сделали, а меня забанили на сутки. Суток мне хватило, я туда больше не вернулся. Я ушёл на oberspace: http://oberspace.dyndns.org/index.php/topic,170.0.html
Re[44]: Оберон круче всех!
От: SenorProgramador Голландия riogamestudio.com
Дата: 11.09.12 01:07
Оценка: -2 :)
Здравствуйте, WolfHound, Вы писали:

V>>Базы данных, конфиги, логи и т.д. до бесконечности тоже через OpenDigalog открывать?

WH>Логи и конфиги монжно и нужно хранить с приватном хранилище. Нехрен их где попало разбрасывать.
WH>Базы данных чуть менее чем всегда можно хранить в локальном хранилище.
WH>А для тех редких случаев, что нельзя никто не мешает данному приложению дать постоянное разрешение на доступ к конкретному файлу.
WH>Для пользователя будет все тот же OpenFileDigalog но с предупреждением что приложение получает постоянный доступ.
WH>Ну и ессно будет список файлов, к которым у приложения есть постоянный доступ и возможность убрать оттуда файл.

WH>Блин. Ну никакой фантазии.


Не могу удержаться: ))))
Вы изобрели реестр виндоус: WH>Логи и конфиги монжно и нужно хранить с приватном хранилище. Нехрен их где попало разбрасывать.

Доступ к БД согласно предоставленным правам: WH>Базы данных чуть менее чем всегда можно хранить в локальном хранилище.
WH>А для тех редких случаев, что нельзя никто не мешает данному приложению дать постоянное разрешение на доступ к конкретному файлу.

И антивирус вкупе с файеволом встроенный в ОС:
WH>Для пользователя будет все тот же OpenFileDigalog но с предупреждением что приложение получает постоянный доступ.
WH>Ну и ессно будет список файлов, к которым у приложения есть постоянный доступ и возможность убрать оттуда файл.

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

Тем самым уподобляясь несчастным апологетам того же несчастного оберона)))) по сути.

Почитатели каких то сферических коней в вакууме, ей-богу.

Не знаю как там в вашей вселенной абстракционистов-теоретиков, у нас у практиков прекрасно работает и Виндоуз и МакОС и Линукс и Андроид с иОСом,
прекрасно пишем на плюсах, жабе, шарпе))
Вы активно защищаете какие то идеи, которые никому массово не нужны. Никаких проблем они не решают, а только добавляют хлопот.
Потому как идеи эти уже давно реализованы и работают и пользу приносят и зарабатывают деньги.
Veni, vidi, vici
I came, I saw, I conquered
Re[45]: Оберон круче всех!
От: Cyberax Марс  
Дата: 11.09.12 01:55
Оценка: 1 (1)
Здравствуйте, SenorProgramador, Вы писали:

SP>Вроде ж грамотный человек, но непонятно почему вы пытаетесь представить давно известные общественности вещи

SP>как нечто совершенно новое, полет мысли, панацея, квинтессенция и прочее бла-бла-бла.
Кто-то разве говорит про "совершенно новое"? Указанные технологии — это вариация на тему "capability based security", которой уже фиг знает сколько лет (30 как минимум точно есть).
Sapienti sat!
Re[45]: Оберон круче всех!
От: WolfHound  
Дата: 11.09.12 08:16
Оценка:
Здравствуйте, SenorProgramador, Вы писали:

WH>>Логи и конфиги монжно и нужно хранить с приватном хранилище. Нехрен их где попало разбрасывать.

SP>Вы изобрели реестр виндоус:
Мимо. Реестр винды это глобальная помойка, в которую кто попало, куда попало может гадить.
И хрен найдешь, кто, что и куда записал.

В данном случае приложение за приделы своей песочницы нагадить не может физически.

Таким образом, приложение полностью автоматически можно удалить без следа. Деинсталятор вшит прямо в ОС.

WH>>Базы данных чуть менее чем всегда можно хранить в локальном хранилище.

SP>Доступ к БД согласно предоставленным правам:
Опять мимо. Ибо разговор снова про личную БД приложения за приделы которой оно физически не может сунуться.
При этом от пользователя нужно ровно 0 настройки.

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

WH>>Ну и ессно будет список файлов, к которым у приложения есть постоянный доступ и возможность убрать оттуда файл.
SP>И антивирус вкупе с файеволом встроенный в ОС:
Опять не попал.
Антивирус это эвристическая программа, которая ловит зловредов с некоторой вероятностью.
В данном случае они физически ничего сделать не могут.

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

Вещи то старые. Но ты ни разу не угадал.

SP>Не знаю как там в вашей вселенной абстракционистов-теоретиков, у нас у практиков прекрасно работает и Виндоуз и МакОС и Линукс и Андроид с иОСом,

Я вижу, как они работают.
Вирусы. Dllhell. Не работающий софт по причине смены набора команд процессора.

SP>прекрасно пишем на плюсах, жабе, шарпе))

Я вижу, как вы пишете. Жрете память. Ломаете её. Создаете кучу дырок для вирусов. Тормозите на ровном месте. Не можете масштабироваться.

SP>Вы активно защищаете какие то идеи, которые никому массово не нужны. Никаких проблем они не решают, а только добавляют хлопот.

640К хватит всем. (С)
Если ты что-то не понимаешь, это не значит что это не нужно.

SP>Потому как идеи эти уже давно реализованы и работают и пользу приносят и зарабатывают деньги.

В том то и дело что нихрена они не реализованы.
Вернее реализованы, но кусочками, а нужно комплексное решение.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[44]: Оберон круче всех!
От: vdimas Россия  
Дата: 11.09.12 13:00
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

WH>Его нет.

Есть. Это атомарный счетчик.

WH>Также как нет базовой вычислительной модели.

WH>Все выражается друг через друга.

Попытка дать док-во по аналогии.


WH>Но что характерно ты так и не предоставил мне решение одной простой задачки.


Какой именно?


WH>Короче напиши readMVar или засчитываю слив.


Или идешь лесом. Я уже более одного раза предлагал тебе подумать над сценарием передачи данных м/у потоками через некое поле, когда речь идет о типе данных, для которого атомарность гарантируется аппаратурой. Например, когда речь об указателе. Фишка в том, что для сигналинга все-равно потребуется некий примитив синхронизации, на котором можно ожидать "готовность" данных.


WH>Авторам библиотеки удалось лишь с такой оговоркой.

WH>

WH>This function is atomic only if there are no other producers (i.e. threads calling putMVar) for this MVar.

WH>Попробуй понять почему.

Что именно понять? Их MVar делается, например, на 2-х семафорах со счетчиком равным 1, или одном семафоре и одном мьютексе. Есть еще вариант — на 1-м мьютексе + sleep() как ожидание. Есть еще вариант на conditional variable, если такая функциональность поддерживается ОС.

Кароч, есть куча полностью атомарных и безопасных реализаций для организации межпоточного обмена. Ограничения могут быть только если пытаться делать блокировки "легковесными", типа как в lock-free алгоритмах.


WH>Плюс тебе еще задачка сделать await. На данных примитивах будет просто гора кода.

WH>И я даже не уверен, что его можно сделать с одной MVar.

Потому что не понимаешь как работает полноценный conditional variable. Классический AWAIT требует PULSE, а последнее требует поддержки очереди ожидающих. Вопрос горы кода зависит от того, есть ли аналог conditional variable в АПИ ОС, или её надо делать самому. В прямом виде для Windows нет, например. Но коссвенно, через completion ports, можно задействовать внутреннюю очередь виндов для аналогичного механизма (см. boost::asio для виндов, где можно диспатчить свои события, а не только системные). Просто этот механизм — именно такой, о котором речь (для асинхронных операций IO, которые реализованы по технологии completion ports в виндах).


WH>Всю свою демагогию про продолжения ты тоже, что характерно слил.


Слил ты про свой мега-TDOP, который не работает на простейшем куске С++ исходника.
Зато сколько было гонору... не? )))

А я ничего не сливал. По ссылке завис мой неотвеченный пост: http://www.rsdn.ru/forum/philosophy/4831188.1.aspx
Автор: vdimas
Дата: 26.07.12

Если есть чего по нему ответить — велкам.
Re[45]: Оберон круче всех!
От: WolfHound  
Дата: 11.09.12 13:27
Оценка:
Здравствуйте, vdimas, Вы писали:

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

WH>>Его нет.
V>Есть. Это атомарный счетчик.
Показать тебе атомарный счетчик, реализованный на любом другом примитиве синхронизации?

WH>>Также как нет базовой вычислительной модели.

WH>>Все выражается друг через друга.
V>Попытка дать док-во по аналогии.
Нет. Просто констатация факта.

WH>>Короче напиши readMVar или засчитываю слив.

V>Или идешь лесом.
Слив засчитан. Тем более что ты несешь просто феерический бред про "базовый примитив синхронизации".
После такого разговаривать с тобой просто нет смысла. Ибо ты полностью безграмотен.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[46]: Оберон круче всех!
От: vdimas Россия  
Дата: 11.09.12 19:31
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

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

WH>>>Его нет.
V>>Есть. Это атомарный счетчик.
WH> Показать тебе атомарный счетчик, реализованный на любом другом примитиве синхронизации?

Ну, покажи, поржем...
Потому как тот "другой" примитив синхронизации будет уже внутри себя содержать счетчик. Не пробовал на досуге посмотреть устройство хотя бы юзер-левельного CRITICAL_SECTION?

WH>>>Также как нет базовой вычислительной модели.

WH>>>Все выражается друг через друга.
V>>Попытка дать док-во по аналогии.
WH>Нет. Просто констатация факта.

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


WH>>>Короче напиши readMVar или засчитываю слив.

V>>Или идешь лесом.
WH>Слив засчитан.

Гы-гы. Я тебе дал навскидку 3 варианта с ходу, считая их известными. Просто ты их не в курсе, очевидно. Например, покажи механизм сигналинга на первом же варианте из вариантов — двух семафорах со счетчиком 1. А ведь классика жанра, казалось бы.

Про AWAIT мы, походу, испарились. ЧТД.

WH>Тем более что ты несешь просто феерический бред про "базовый примитив синхронизации".

WH>После такого разговаривать с тобой просто нет смысла. Ибо ты полностью безграмотен.

Фи как быстро и далеко мы опять убежали. Ню-ню. По-существу, замечание/дополнение насчет счетчика есть и я специально оставил этот вопрос открытым, надеясь тебя поймать.
Но ты оч быстро бегаешь, не вышло. По сути предмета я имею ввиду механизм ожидания на этом счетчике, реализованный через шедуллер ОС. Просто это было бы опасное замечание для того, кто не в курсе, как это всё на самом деле работает. Я не зря посоветовал покурить устройство этих примитивов внутри ОС. В любом случае, в коде того самого ядра, реализующего всю механику, без атомарных счетчиков не обойтись (или флагов, который вырождается в счетчик со значением 1), коль вызовы самого ядра могут быть многопоточными. Но твои предложения выразить одни примитивы через другие говорят о том, что ты мыслишь настолько далекими от устройства этих примитивов понятиями, что действительно, нам с тобой обсуждать сразу нечего. Ты ведь исходишь из того, что некие примитивы синхронизации у тебя УЖЕ есть... по мановению волшебной палочки, очевидно... И даже не мелькнуло мысли, а как же это может работать, если ты выполняешь код ядра??? Вот это гы-гы, так гы-гы.
Re[46]: Оберон круче всех!
От: SenorProgramador Голландия riogamestudio.com
Дата: 11.09.12 19:38
Оценка:
Здравствуйте, WolfHound, Вы писали:

...много бла-бла-бла...

Вы как будто из лесу вышли с криками: "смотрите, я увидел солнце!" ))
"Это новая звезда и имя ей -- сингулярити!" ))

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

Посмотрите, хотя бы на андроид -- ну, каждое приложение имеет список пермишнов -- и что?
Почти каждое -- требует целую кучу -- и юзер послушно разрешает.

В иОСе -- премодерация всех легальных приложений -- малвари не пройти, а если и пройти -- то очень недалеко.
Опять же, покупки и настройки и так сохранаяются и переносятся на другое устройство.

И, кстати, и приложения подписываются уникальным ключом разработчика, все это есть уже давно.

Что вы нового пропагандируете и какие проблемы обычного юзера и/или разработчика решаете -- непонятно.

P.S.: я не ради просто поддержания дискуссии, и не с целью каких то словесных нападений, мне кажется, что вы уж слишком рьяно
пытаетесь доказать какие то тезисы, которые уже давно не то, чтобы доказаны, а давно уже работают.
Veni, vidi, vici
I came, I saw, I conquered
Re[46]: Оберон круче всех!
От: vdimas Россия  
Дата: 11.09.12 22:36
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>Короче напиши readMVar или засчитываю слив.

V>>Или идешь лесом.
WH>Слив засчитан.

Ладно, не ожидал, прямо скажем, такого:

Короче напиши readMVar или засчитываю слив.
Авторам библиотеки удалось лишь с такой оговоркой.
This function is atomic only if there are no other producers (i.e. threads calling putMVar) for this MVar.
Попробуй понять почему.

от конкретно тебя... Похоже, упор исключительно на дотнет даром не проходит...

Простой сигналинг при межпотоковой передаче таков: поток-producer должен получать сигнал, что можно писать, а поток-consumer должен получать сигнал о том, что можно читать. Поэтому, очевидное (и, кстати, самое эффективное в случае большой вероятности захода потоков на ожидание) — это решение "в лоб":

template<typename T>
class MVar
{ 
  Semaphore readSema_, writeSema_;
  T volatile value_;

  MVar() : writeSema_(1) {}

  MVar(const T & value) : value_(value), readSema_(1) {}

  void write(const T & value) {
    writeSema_.acquire(), value_ = value, readSema_.release();
  }

  T read(const T & value) {
    T tmp;
    readSema_.acquire(), tmp = value_, writeSema_.release();
    return tmp;
  }
};


Дарю!
Остальные упомянутые мной способы реализации приводить? ))

В общем, вот элементарная реализация, которая абсолютно безопасна безо-всяких твоих оговорок. А попробовать понять (как ты просил), почему у авторов исходного MVar не получилась реализация без оговорок... предположу, что кривизна рук не того радиуса.

И да, эту реализацию где-то можно рассматривать как очередь с одним элементом... эт даааа... Я всегда привожу пример Матлаба, где скаляры на самом деле матрицы [1,1].
Но там это хоть имеет все основания для такого обобщения без дополнительных приседаний в семантике и реализации, а в случае MVar — увы, нет... потому что если длина очереди будет >1 (если инициализировать семафоры значением макс. длины очереди), то показанная реализация не будет работать. Будет нужен дополнительный примитив синхронизации для разруливания конкурентного доступа к самой очереди. В общем, для межпотоковой очереди подходящи совсем ДРУГИЕ алгоритмы...

Ну а то, что MVar можно использовать как семафор со счетчиком 1, если игнорить само значение... Это уже просто поражает той бедностью, которой готовы обходиться хаскелисты... См. приведенную реализацию, мысленно убери оттуда операции с value_ и будет видно, что из двух семафоров один лишний, если требуется именно семафор. )) В общем, классичесский подход, когда примитивы синхронизации доступны в явном виде, на порядки мощнее этого убожества под именем MVar... да еще которое криво реализовали...
Re[47]: Оберон круче всех!
От: WolfHound  
Дата: 12.09.12 08:26
Оценка:
Здравствуйте, vdimas, Вы писали:

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

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

V>Про AWAIT мы, походу, испарились. ЧТД.

Это для тебя слишком сложный разговор. Ты сначала MVar пойми.

V>Фи как быстро и далеко мы опять убежали. Ню-ню. По-существу, замечание/дополнение насчет счетчика есть и я специально оставил этот вопрос открытым, надеясь тебя поймать.

Ты не можешь меня поймать. У тебя просто знаний не хватит.

V>Но ты оч быстро бегаешь, не вышло. По сути предмета я имею ввиду механизм ожидания на этом счетчике, реализованный через шедуллер ОС. Просто это было бы опасное замечание для того, кто не в курсе, как это всё на самом деле работает.

Не волнуйся. Я в курсе. Причем намного лучше, чем ты.

V>Я не зря посоветовал покурить устройство этих примитивов внутри ОС. В любом случае, в коде того самого ядра, реализующего всю механику, без атомарных счетчиков не обойтись (или флагов, который вырождается в счетчик со значением 1), коль вызовы самого ядра могут быть многопоточными.

Одна из реализаций hardware transactional memory

RTM adds three new instructions XBEGIN, XEND and XABORT. The XBEGIN and XEND instructions mark the start and the end of a transactional code region; the XABORT instruction explicitly aborts a transaction. Transaction failure redirects the processor to the fallback code path specified by the XBEGIN instruction, with the abort status returned in the EAX register.

Начинай считать счетчики.

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

Я просто понимаю, что с теоритической точки зрения одни примитивы можно выразить через другие. Точно так же как один полный по Тьюрингу язык можно реализовать на другом. Эффективность в данном случае вопрос десятый.
При этом не важно, какие нам даны.
Если нам ничего не дано, то мы не сможем ничего сделать.

V>Ты ведь исходишь из того, что некие примитивы синхронизации у тебя УЖЕ есть... по мановению волшебной палочки, очевидно... И даже не мелькнуло мысли, а как же это может работать, если ты выполняешь код ядра??? Вот это гы-гы, так гы-гы.

Это у тебя не мелькнуло мысли о том, что железо может быть очень разным.
Короче начинай считать счетчики в инструкциях XBEGIN, XEND и XABORT.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[47]: Оберон круче всех!
От: WolfHound  
Дата: 12.09.12 08:26
Оценка:
Здравствуйте, vdimas, Вы писали:

V>от конкретно тебя... Похоже, упор исключительно на дотнет даром не проходит...

Ты даже не представляешь, насколько смешон.

V>Дарю!

V>Остальные упомянутые мной способы реализации приводить? ))
Поздравляю. Ты реализовал getMVar и putMVar.
Теперь используя только getMVar и putMVar реализуй readMVar.
Который читает значение, при этом не забирает его.
Доступа к семафорам у тебя нет. Использовать можно только публичный интерфейс.

V>Ну а то, что MVar можно использовать как семафор со счетчиком 1, если игнорить само значение... Это уже просто поражает той бедностью, которой готовы обходиться хаскелисты... См. приведенную реализацию, мысленно убери оттуда операции с value_ и будет видно, что из двух семафоров один лишний, если требуется именно семафор. )) В общем, классичесский подход, когда примитивы синхронизации доступны в явном виде, на порядки мощнее этого убожества под именем MVar... да еще которое криво реализовали...

Ты понимаешь что, используя одни примитивы можно получить другие.
Это уже прогресс.
Но твоя зацикленность на листьях просто поражает. Вместо анализа модели ты начал анализировать одну из возможных её реализаций. При использовании HTM реализация будет сильно другая. И весь твой анализ сразу отправляется в мусор.
А теперь попробуй представить страшное... MVar реализован процессором. И других примитивов синхронизации в железе нет.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[47]: Оберон круче всех!
От: WolfHound  
Дата: 12.09.12 08:48
Оценка:
Здравствуйте, SenorProgramador, Вы писали:

SP>Про десктопы и десктопные оси в перспективе можете забыть вообще.

SP>Они вымрут как динозавры, ибо уже грянул мобайл. (это насчет вашего неправомерного отсыла в прошлое с 640 Кб)
1)Никуда десктоп не денется. Мобаил просто не может решать все задачи.
2)У мобайла ровно те же проблемы.
3)640К было не про то о чем ты подумал. А про то, что не нужно говорить о том, что что-то не нужно, если ты не знаешь, зачем это нужно.

SP>Посмотрите, хотя бы на андроид -- ну, каждое приложение имеет список пермишнов -- и что?

SP>Почти каждое -- требует целую кучу -- и юзер послушно разрешает.
1)Гранулярность у них слишком маленькая.
2)Я не разрешаю, если вижу что-то что приложению не нужно.
Например, читалка штрихкодов захотела доступ к моим контактам. Зачем? Была послана.
А если бы я был модератором, то еще бы и забанена.

SP>В иОСе -- премодерация всех легальных приложений -- малвари не пройти, а если и пройти -- то очень недалеко.

Вот тут профессионал и проверит, зачем приложению нужны все те привилегии, что оно запрашивает.
Скорость модерации возрастет на порядки просто по тому, что в большинстве случаев будет достаточно посмотреть, что приложение не просит то, что ему не нужно.

SP>Опять же, покупки и настройки и так сохранаяются и переносятся на другое устройство.

Это вообще отдельный разговор и к безопасности отношения не имеет.

SP>И, кстати, и приложения подписываются уникальным ключом разработчика, все это есть уже давно.

Вот это как раз не обязательно.

SP>Что вы нового пропагандируете и какие проблемы обычного юзера и/или разработчика решаете -- непонятно.

Ессно не понятно. Для этого же нужно много изучить. И это трудно. А просто болтать языком, что все те, кто говорит что-то непонятное идиоты, очень легко.

SP> пытаетесь доказать какие то тезисы, которые уже давно не то, чтобы доказаны, а давно уже работают.

К сожалению не работают. Ибо даже если всё обложить подписями и модераторами, то банальные ошибки переполнения буфера всё испортят.
И это не говоря про такие мелочи как возможность приложению засунуть свои плагины в песочницу. Ибо ничто не мешает плагину вызывать функции ОС с правами приложения.
Например, если я пишу, видело плеер, то я должен быть уверен, что кодек, который я использую, на самом деле не малварь и не лезет куда попало. Что ты будешь делать в классических ОС, чтобы не дать ему запустить свои грязные лапы, куда не следует?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[48]: Оберон круче всех!
От: vdimas Россия  
Дата: 12.09.12 14:13
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

WH>Твои знания ничтожны. Ибо ты изучаешь даже не деревья, а листья на них.
WH>Но при этом говоришь про лес в целом.

Как всегда, десяток постов сплошного бла-бла-бла... Пока опять не поймали.
Характерно, что ты уцепился за базовый уровень 0 по этой теме, и назвал этот уровень "лесом".
Я с тобой лично не знаком... но уже предлагал как-то поспорить на тот счет, что ты безбожно прогуливал во время учебы в ВУЗе. То, что ты назвал "лесом", дается на 3-4-х лекциях по устройству ОС. Ты на них не был, очевидно. Это банальности, а никакой не лес. Если я их не упоминаю, то лишь от того, что мы на проф-форуме.


V>>Про AWAIT мы, походу, испарились. ЧТД.

WH>Это для тебя слишком сложный разговор. Ты сначала MVar пойми.

Фишка в том, что кол-во необходимых примитивов синхронизации для "честного" сигналинга всё-равно будет таким же, как на самом простом из них... кроме случая отказа от сигналинга ОС и использования вместо него тупого мьютекса (крит.секции) + sleep(). Я по-наивности своей считал, что намеков было более чем достаточно... но всё это действительно для кое-кого оч сложно. В общем, ты много пальцы вейром растопыривал, а сколько нужно примитивов синхронизации для MVar так и не сказал. ЧТД.


V>>Фи как быстро и далеко мы опять убежали. Ню-ню. По-существу, замечание/дополнение насчет счетчика есть и я специально оставил этот вопрос открытым, надеясь тебя поймать.

WH>Ты не можешь меня поймать. У тебя просто знаний не хватит.

Угу, с альфой и обделавшимся TDOP тоже не хватило. Натуральный парадокс блабла уже выходит. Только теперь в цикле.



V>>Я не зря посоветовал покурить устройство этих примитивов внутри ОС. В любом случае, в коде того самого ядра, реализующего всю механику, без атомарных счетчиков не обойтись (или флагов, который вырождается в счетчик со значением 1), коль вызовы самого ядра могут быть многопоточными.

WH>Одна из реализаций hardware transactional memory
WH>

WH>RTM adds three new instructions XBEGIN, XEND and XABORT. The XBEGIN and XEND instructions mark the start and the end of a transactional code region; the XABORT instruction explicitly aborts a transaction. Transaction failure redirects the processor to the fallback code path specified by the XBEGIN instruction, with the abort status returned in the EAX register.

WH>Начинай считать счетчики.

Ох, блин, вики открыл? Какая прелесть! А теперь попробуй найтии отличие от обычного CAS, для случая данных шириной в слово.

Это я еще молчу о том, что ни в твоей, ни в моей машинке этой памяти пока нет. Ууупс?


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

WH>Я просто понимаю, что с теоритической точки зрения одни примитивы можно выразить через другие.

Я рад за тебя... ты прав на все 100%, особенно когда никого не волнует эффективность... Можно даже тупо сидеть в цикле на sleep() и ждать у моря погоды, фигли... Хотя я потрунивал именно над эффективностью этой штуки, когда они показывали нам, в каких сценариях еще можно этот несчастный MVar использовать.


WH>Точно так же как один полный по Тьюрингу язык можно реализовать на другом. Эффективность в данном случае вопрос десятый.


Точно! Речь же о базовом и единственном примитиве синхронизации, доступным из языка... Хотя, это в духе того самого языка, угу. )))


WH>При этом не важно, какие нам даны.

WH>Если нам ничего не дано, то мы не сможем ничего сделать.

Кароч, одни юления и ничего кроме юлений.
В современных SMP-машинках в кольцо ядра спокойно заходят несколько физических потоков. Что значит "ничего не дано"? Этот момент дан свыше и это не переплюнуть. На однопроцессорных машинках просто запрещаются прерывания и выполняется логика конретного примитива синхронизации, но что у нас есть в SMP? — атомарные операции (навроде CAS), к нему spin-wait и самый крайний случай — заморозка текущего потока в шедуллере. Вот твой реальный базис. Действуй. Если бы не было ничего дано, то высокоуровневые примитивы синхронизации в этой среде были бы невозможны.


V>>Ты ведь исходишь из того, что некие примитивы синхронизации у тебя УЖЕ есть... по мановению волшебной палочки, очевидно... И даже не мелькнуло мысли, а как же это может работать, если ты выполняешь код ядра??? Вот это гы-гы, так гы-гы.

WH>Это у тебя не мелькнуло мысли о том, что железо может быть очень разным.
WH>Короче начинай считать счетчики в инструкциях XBEGIN, XEND и XABORT.

Дык, ты всё-равно никоим образом не опровергнул суть вопроса... Вопрос в силе...
Ну будет более одного счетчика/флага за раз изменяться, и? Я тебе по-секрету скажу, что это же самое происходит внутри виндов прямо сейчас, даже на твоей машинке, путем разбиения машиного слова на поля, и пользуя стандартный цикл обновления на CAS. Если бы ты это знал, не приводил бы сейчас тоже самое с точностью до ширины данных. Так что все твои понты дальше Вики не ходят, увы.

И да, базовый алгоритм я тебе рядом привел. Даже если объединить показанные там семафоры в одно слово, все-равно будут 2 последовательные операции независимо по 2-м полям, отведенным под мьютексы.
Re[48]: Оберон круче всех!
От: vdimas Россия  
Дата: 12.09.12 14:16
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


V>>от конкретно тебя... Похоже, упор исключительно на дотнет даром не проходит...

WH>Ты даже не представляешь, насколько смешон.

V>>Дарю!

V>>Остальные упомянутые мной способы реализации приводить? ))
WH>Поздравляю. Ты реализовал getMVar и putMVar.

Дык, реализаций может быть много. Минимум 4 еще я тебе словами описал сразу же. А показал лишь вариант "в лоб", чтобы продемонстрировать те задачи/сигналы, которые возникают при передаче данных м/у потоками. Просто я, по-наивности своей, много постов назад упоминал сии сценарии в словесном описании, думая, что ты владеешь темой... ан нет. А сейчас привел пример исключительно чтобы показать минимально-необходимое кол-во НЕЗАВИСИМЫХ примитивов синхронизации для реализации с стиле "честного" сигналинга ОС, то бишь когда потоки получают управления не для того, чтобы копошиться-проверять готовность (и тратить драгоценные тики ядер на "холостые" переключения контекстов), а когда эта готовность де-факто наличиствует и уже ничего проверятьне надо.

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


WH>Теперь используя только getMVar и putMVar реализуй readMVar.

WH>Который читает значение, при этом не забирает его.
WH>Доступа к семафорам у тебя нет. Использовать можно только публичный интерфейс.

Если это не прикол, а вопрос по-существу, то детсад как он есть. Бери два MVar их и пользуй один из них для эмуляции CAS-цикла, управляющего доступом к другому. Если же речь об одном и том же экземпляре MVar, то вопрос моментально переходит в разряд идиотских.

Или там есть какой-то "встроенный" прикол? (Всё-таки подобную степень идиотизма предположить с ходу мне сложновато)
Или еще что-то? В чем суть, не пояснишь? Даже если не смотреть на идиотскую постановку вопроса, мне вообще необходимость функциональности readMVar, когда речь идет о многопоточности, неочевидна. Это же опять классика — данные могуть стать невалидными сразу же после их прочтения. "Ты понимаешь, почему?" (С).

Например, мы в АПИ своих продуктов (low-latency middleware) стараемся избегать таких методов, т.к. это будет профанация, а не АПИ. Межпоточные дела, по-хорошему, должны работать в стиле push, генерируя последовательность событий. Тогда у клиентов библиотек не будет пространства для детских ошибок.


V>>Ну а то, что MVar можно использовать как семафор со счетчиком 1, если игнорить само значение... Это уже просто поражает той бедностью, которой готовы обходиться хаскелисты... См. приведенную реализацию, мысленно убери оттуда операции с value_ и будет видно, что из двух семафоров один лишний, если требуется именно семафор. )) В общем, классичесский подход, когда примитивы синхронизации доступны в явном виде, на порядки мощнее этого убожества под именем MVar... да еще которое криво реализовали...

WH>Ты понимаешь что, используя одни примитивы можно получить другие.
WH>Это уже прогресс.

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

WH>Но твоя зацикленность на листьях просто поражает. Вместо анализа модели ты начал анализировать одну из возможных её реализаций.


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

WH>При использовании HTM реализация будет сильно другая. И весь твой анализ сразу отправляется в мусор.


Не будет, увы. HTM ты можешь проэмулировать прямо сейчас, разбив машинное слово на поля и пользуя цикл обновления CAS. От двух (минимум) независимых примитивов синхронизации не убежишь никак. Рядом уже написал чуть подробнее.


WH>А теперь попробуй представить страшное... MVar реализован процессором. И других примитивов синхронизации в железе нет.


Упс! Наконец-то ты попался. Причем, именно там, где я тебя и поджидал:

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


В процессоре можно реализовать MVar только если вся остальная OC процессором реализована, как минимум шедуллер логических потоков. Муахахаха... ))
Re[49]: Оберон круче всех!
От: WolfHound  
Дата: 12.09.12 14:58
Оценка:
Здравствуйте, vdimas, Вы писали:

WH>>Поздравляю. Ты реализовал getMVar и putMVar.

V>Дык, реализаций может быть много.
Я тебя не спрашивал про реализации. Я их сам могу придумать больше чем ты.
Я вижу, что ты не понимаешь семантику MVar.
И прошу реализовать простейший механизм, который можно было бы реализовать элементарно, если бы это было правдой.

Для танкистов повторяю, MVar — это простая мутабельная переменная, обложенная локом.

(С)Re[36]: Оберон круче всех!
Автор: vdimas
Дата: 24.07.12

Но ты не можешь это сделать.

V>Если это не прикол, а вопрос по-существу, то детсад как он есть. Бери два MVar их и пользуй один из них для эмуляции CAS-цикла, управляющего доступом к другому. Если же речь об одном и том же экземпляре MVar, то вопрос моментально переходит в разряд идиотских.

Мы тут обсуждаем твоё заявление, которое я процитировал выше.
Если бы MVar имел ту семантику, о которой ты говоришь, то readMVar реализовывался бы элементарно.
Но ты это сделать не в состоянии.

V>Или еще что-то? В чем суть, не пояснишь? Даже если не смотреть на идиотскую постановку вопроса, мне вообще необходимость функциональности readMVar, когда речь идет о многопоточности, неочевидна. Это же опять классика — данные могуть стать невалидными сразу же после их прочтения. "Ты понимаешь, почему?" (С).

Есть сценарии когда это осмысленно.

V>Сорри, но это уже разочарование в уровне состоявшегося обсуждения...

V>Мне как-то сложно было сориентироваться, что ты решил по азам пройтись...
Ессно я пошёл по азам. Ты же их не понимаешь.
Ты их зазубрил, но не понял.

V>В процессоре можно реализовать MVar только если вся остальная OC процессором реализована, как минимум шедуллер логических потоков. Муахахаха... ))

Ты просто фантастически безграмотен. Все что нужно это передача управления ОС когда MVar залочился.
Тебя, надеюсь, не удивляет что загрузка страниц памяти из свопа не в процессоре реализовано.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[24]: Оберон круче всех!
От: Дьяченко Александр Россия  
Дата: 25.09.12 18:02
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Заодно держи список проектов, обленившийся зануда:

V>http://oberoncore.ru/wiki/%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F

V>Не знать про ГЛОНАС — это залет, курсант. Хотя я про спутники намекал не раз... И не знать, кто и для чего изначально разработал популярный сейчас для VS2010 шрифт Excelsior это тоже муа... и далее по тексту.


Как человек который там работает говорю нет там никакого Оберона, может на Оберон смотрели, когда был переход с ассемблера, но сейчас его там нет.

А вот Модула-2 есть, правда тоже не в чистом виде, с расширениями — ассемблерные вставки, передача по ссылке как константу (что-то типа const & в C), препроцессор примерно как в C#, кое какие расширения по управлению инициализицией модулей — может еще чего забыд редко используемое.
... << RSDN@Home 1.2.0 alpha 5 rev. 55>>
Re[50]: Оберон круче всех!
От: vdimas Россия  
Дата: 04.10.12 10:44
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>Поздравляю. Ты реализовал getMVar и putMVar.

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

Мде? Давай ревью приведенной реализации, покажи в ней ошибки.

WH>И прошу реализовать простейший механизм, который можно было бы реализовать элементарно, если бы это было правдой.

WH>

WH>Для танкистов повторяю, MVar — это простая мутабельная переменная, обложенная локом.

WH>(С)Re[36]: Оберон круче всех!
Автор: vdimas
Дата: 24.07.12

WH>Но ты не можешь это сделать.

Я уже показал, как это сделать. А ты дергаешь слова из контекста, как всегда, впрочем. Там было сказано, мною же, про межпоточную передачу данных. Так вот, на одном примитиве синхронизации ты это сделаешь только тогда (опять же было сказано), когда сам доступ к переменной атомарный — например, если хранятся только боксированные типы и чтение/запись на платформе атомарны. Ну и опять же, та фраза была сказана не в контексте разбора работы MVar, а в контексте спора — мутабельная ли эта переменная или нет. Сам характер блокировки там не оговаривался. Я вообще не в курсе, какой был смысл обсуждать механизм MVar, если независимо от логики блокировки у нас остаётся мутабельная переменная?

Ну и, про некий составной тип из двух MVar я тебе уже сказал. На нем в точности можно воспроизвести логику обычной CRITICAL_SECTION (если не придираться к эффективности). То бишь, имеем что имеем — внесение банальных привычных мутабельных переменных, обложенных локами, в священную иммутабельную корову — Хаскель. Вот тебе вся твоя "особенная" многопоточность для Хаскеля. Привычный синхронизируемый императив.

V>>Если это не прикол, а вопрос по-существу, то детсад как он есть. Бери два MVar их и пользуй один из них для эмуляции CAS-цикла, управляющего доступом к другому. Если же речь об одном и том же экземпляре MVar, то вопрос моментально переходит в разряд идиотских.

WH>Мы тут обсуждаем твоё заявление, которое я процитировал выше.
WH>Если бы MVar имел ту семантику, о которой ты говоришь, то readMVar реализовывался бы элементарно.

Это ты сам с собой споришь. Я не приводил на тот момент подробной механики работы MVar, чтобы ты делал хоть какие-то выводы. Зато намекнул на conditional variables, которые легко делаются на MVar. Ты, надеюсь, в курсе, что "честные" ConditionalVariables на одном мьютексте воспроизвести невозможно?

В общем, речь там шла лишь о той самой "философии" работы с многопоточностью. А коль ты упорно зацепился за механику — я тебе её привел: http://www.rsdn.ru/forum/philosophy/4889023.1
Автор: vdimas
Дата: 12.09.12
. Есть желание обсуждать мои слова, а не свои фантазии — обсуждай. Нет — нет.

WH>Но ты это сделать не в состоянии.


Гы-гы. Прекрасный образец причины, которая мешает тебе трезво/критично мыслить последние годы. Молодца.


V>>Или еще что-то? В чем суть, не пояснишь? Даже если не смотреть на идиотскую постановку вопроса, мне вообще необходимость функциональности readMVar, когда речь идет о многопоточности, неочевидна. Это же опять классика — данные могуть стать невалидными сразу же после их прочтения. "Ты понимаешь, почему?" (С).

WH>Есть сценарии когда это осмысленно.

Нету.

(Если раскрыть тему:
А толку, если гарантий никаких? Т.е. абсолютно никаких. Т.е. зачем тогда Хаскель, если его берут исключительно из-за гарантий, даваемых языком?
Итого: самостоятельных подобных безопасных сценариев в природе нету. Эта операция безопасна лишь будучи управляемой дополнительной блокировкой обязательного объемлющего сценария.)

V>>Сорри, но это уже разочарование в уровне состоявшегося обсуждения...

V>>Мне как-то сложно было сориентироваться, что ты решил по азам пройтись...
WH>Ессно я пошёл по азам. Ты же их не понимаешь.
WH>Ты их зазубрил, но не понял.

Гы-гы. А мне тут кажется нечто другое. Обычная поверхностность и желание уколоть собеседника хоть чем-то. Ты же влез не туда и спорил не о том, о чем был спор. Изначально я утверждал и возможноти многопоточности лишь на продолжениях в среде честной иммутабельности... А как только я, так и быть, пошел у тебя на поводу, т.е. решил таки пообсуждать навязанную тобой тему относительно механики происходящего (а не общий взгляд на происходящие вещи), ты опять убежал. В общем, это уже никакой не фан для меня, т.к. бестолковость твоих манер ведения споров превышает разумные пределы. Слишком быстро скачешь. Лишний раз отвечать тебе банально лень. Напишешь мало — ты будешь гадать за собеседника. Напишешь много — ты будешь бегать исключительно по верхам и придумывать своей беготне оправдания, одно нелепее другого. Утомил уже.


V>>В процессоре можно реализовать MVar только если вся остальная OC процессором реализована, как минимум шедуллер логических потоков. Муахахаха... ))

WH>Ты просто фантастически безграмотен. Все что нужно это передача управления ОС когда MVar залочился.

Вот, второй раз подряд ты попался, именно где тебя ждут.

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


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

(Характерно, что все подсказки я дал буквально здесь же... и ты всё-равно опять вляпался).
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.