Size: a a a

2020 August 20

SB

S B in F# Chat
TES
чёто ты уже к дизайну БД съезжаешь
это не дизайн БД, это мера изоляции.
источник

SB

S B in F# Chat
A - C - Isolation - D
источник

AV

Alex Varenik in F# Chat
TES
из за изменения подхода к написанию программы, не совсем понятно где и когда что использовать. возможно есть какой-то принятый стандарт.
Какой подход/ЯП используешь сейчас?
источник

T

TES in F# Chat
Alex Varenik
Какой подход/ЯП используешь сейчас?
F#
источник

T

TES in F# Chat
Alex Varenik
Кодирование без блокировок с помощью разделяемых
классов Теория синхронизации, основанной на
блокировках, сформировалась в 1960-х. Но уже к 1972
году [23] исследователи стали искать пути исключения из
многопоточных программ медленных, неуклюжих мьютексов,
насколько это возможно. Например, операции присваивания
с некоторыми типами можно было выполнять атомарно, и
программисты осознали, что охранять такие присваивания
с помощью захвата мьютексов нет нужды. Кроме того,
некоторые процессоры стали выполнять транзакционно и
более сложные операции, такие как атомарное увеличение
на единицу или «проверить- и-установить ». Около
тридцати лет спустя, в 1990 году, появился луч надежды,
который выглядел вполне определенно: казалось, должна
отыскаться какая- то хитрая комбинация регистров для
чтения и записи, позволяющая избежать тирании
блокировок. И в этот момент появилась полная
плодотворных идей работа, которая положила конец
исследованиям в этом направлении, предложив другое.
Статья Мориса Херлихи «Синхронизация без ожидания »
(1991) [3] ознаменовала мощный рывок в развитии
параллельных вычислений. До этого разработчикам и
аппаратного, и программного обеспечения было одинаково
неясно, с какими примитивами синхронизации лучше всего
работать. Например, процессор, который поддерживает
атомарные операции чтения и записи значений типа int,
интуитивно могли счесть менее мощным, чем тот, который
помимо названных операций поддерживает еще и атомарную
операцию +=, а третий, который вдобавок предоставляет
атомарную операцию *=, казался еще мощнее. В общем, чем
больше атомарных примитивов в распоряжении
пользователя, тем лучше. Херлихи разгромил эту теорию,
в частности показав фактическую бесполезность
казавшихся мощными примитивов синхронизации, таких как
«проверить- и-установить », «получить- и-сложить » и
даже глобальная разделяемая очередь типа FIFO. В свете
этих парадоксов мгновенно развеялась иллюзия, что из
подобных механизмов можно добыть маги13.16. Кодирование
без блокировок с помощью разделяемых классов 511 ческий
эликсир для параллельных вычислений. К счастью, помимо
получения этих неутешительных результатов Херлихи
доказал справедливость выводов об универсальности:
определенные примитивы синхронизации могут теоретически
синхронизировать любое количество параллельно
выполняющихся потоков. Поразительно, но реализовать
«хорошие » примитивы ничуть не труднее, чем «плохие »,
причем на невооруженный глаз они не кажутся особенно
мощными. Из всех полезных примитивов синхронизации
прижился лишь один, известный как сравнение с обменом
(compare-and-swap). Сегодня этот примитив реализует
фактически любой процессор. Семантика операции
сравнения с обменом: // Эта функция выполняется
атомарно

bool cas(T)(shared(T) * here, shared(T) ifThis, shared(T) writeThis)
{   if (*here == ifThis)
 {
   *here = writeThis; return true;
 }
return false;
}
В переводе на обычный язык операция cas атомарно
сравнивает данные в памяти по заданному адресу с
заданным значением и, если значение в памяти равно
переданному явно, сохраняет новое значение; в противном
случае не делает ничего. Результат операции сообщает,
выполнялось ли сохранение. Операция cas целиком
атомарна и должна предоставляться в качестве примитива.
Множество возможных типов T ограничено целыми числами
размером в слово той машины, где будет выполняться код
(то есть 32 и 64 бита). Все больше машин предоставляют
операцию сравнения с обменом для аргументов размером в
двойное слово (double-word compare-and-swap), иногда ее
называют cas2. Операция cas2 автоматически обрабатывает
64-битные данные на 32-разрядных машинах и 128-битные
данные на 64-разрядных машинах. Ввиду того что все
больше современных машин поддерживают cas2, D
предоставляет операцию сравнения с обменом для
аргументов размером в двойное слово под тем же именем
(cas), под которым фигурирует и перегруженная
внутренняя функция. Так что в D можно применять
операцию cas к значениям типов int, long, float,
double, любых массивов, любых указателей и любых ссылок
на классы.
а что товарищь Херлихи говорит по поводу синхронизации записи блоков данных?
источник

T

TES in F# Chat
Alex Varenik
Какой подход/ЯП используешь сейчас?
или ты имеешь ввиду в работе? тогда C#
источник

AV

Alex Varenik in F# Chat
TES
а что товарищь Херлихи говорит по поводу синхронизации записи блоков данных?
Насколько я понимаю, рантайм ЯП следит за ссылками иммутабельного объекта, которые в конечном счете представляют собой примитивы, нет?
источник

P

Pavel in F# Chat
TES
или ты имеешь ввиду в работе? тогда C#
А как на c# решаеш такую же задачу?
источник

T

TES in F# Chat
Alex Varenik
Насколько я понимаю, рантайм ЯП следит за ссылками иммутабельного объекта, которые в конечном счете представляют собой примитивы, нет?
а если тебе нужно атомарно несколько полей в объекте поменять?
источник

T

TES in F# Chat
Pavel
А как на c# решаеш такую же задачу?
локами
источник

AV

Alex Varenik in F# Chat
TES
или ты имеешь ввиду в работе? тогда C#
Ну, тогда понятно, не смотри серии F# для C#. Смотри со стороны реализации конкретной логики. В C# принято сначала архитектуру сделать. В F# описать систему как набор типов (компибнация суммы(DU) и произведения(records)) и затем реализовать обработку этих типов. Если нужно потом связать все вместе с помощью ООП и почтовых ящиков. 👌
источник

SB

S B in F# Chat
вообще, попытка разруливать такие вещи на уровне приложения - самый правильный способ наебнуть консистентность. в итоге у тебя рано или поздно отъебнет связка между БД и приложением, они начнут смотреть на мир по-разному и это произойдет в субботу в 3 утра.
источник

T

TES in F# Chat
всё, я понял посыл. нет смысла менять подход. проблема решается так же, как и в других языках, а мейлбокс - это просто надстройка над очередью
источник

AV

Alex Varenik in F# Chat
Pavel
А как на c# решаеш такую же задачу?
источник

P

Pavel in F# Chat
TES
локами
Дак и на фшарпе реши с локом, нет тут смены подхода)
источник

T

TES in F# Chat
Pavel
Дак и на фшарпе реши с локом, нет тут смены подхода)
читай выше) но спасибо за наводку на мысль
источник

AV

Alex Varenik in F# Chat
источник

T

TES in F# Chat
почему-то никогда не видел, чтобы кто-то его использовал. поэтому и сам отношусь к нему с недоверием. локи кажутся более надёжными
источник

SB

S B in F# Chat
TES
почему-то никогда не видел, чтобы кто-то его использовал. поэтому и сам отношусь к нему с недоверием. локи кажутся более надёжными
так это традиционно гораздо более продвинутый уровень. и кроме того, эти туториалы не покрывают ABA-проблему, которая часто на практике имеет смысл.
источник

AV

Alex Varenik in F# Chat
TES
почему-то никогда не видел, чтобы кто-то его использовал. поэтому и сам отношусь к нему с недоверием. локи кажутся более надёжными
Используют когда логика сложная, а проблему решать надо 😀
источник