Снова о статической типизации

В языках с иммутабельностью таких проблем не возникает

Такая «статическая» проверка называется дебаг :D. Если 100500 if по динамическим условиям влияют на то будет ли сейчас захват или игнор мутекса то хрен чего отловишь. Максимум что можно проверить это проставлены ли вызовы проверки мутекса и его захвата в коде и в том ли порядке, всё. Ну как по мне. А дальше там что угодно может происходить.

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

Это я к тому что типизация тут непричём от слова ваще, тут специализированные тулзы нужны специально проверяющие что некие хни должны быть упорядоченны в вызовах на основе мутексов…

Ой…. Стой, ты имеешь в виду нужно вводить тип? Ну типа

int mutexable foo();
int mutexable bar();

И конпелятор помимо проверок типов должен ещё проверять что мутексаблинутые хехе функции корректно будут захватывать и отпускать блокировки?

Опять же, всё это здорово но установка мутекса ничем не отличается от вызова функции, это не совсем то что вообще относится к типизации как таковой

Ложки нет, Нео.

Не ну понятно что функций нет, прыг и всё, вот и всё что есть. Но я… ну блин. Ой ладно, я просто почитаю чего тут напишут.

with _lock:
  # все что внутри блокируется для модификации другими процессами 

И вот… тупизации нет, а защита есть. К чему тема-то?

Ты на чём писал ДО? Такое, как ты не знаешь подходы. Ну так учи.

все что внутри блокируется для модификации другими процессами

Потрясающее открытие. Ты изобрел мьютексы. Поздравляю.

да, я тебе показал как в питоне оно работает

Ой ладно, я просто почитаю чего тут напишут.

Судя по первым комментариям, тут будут только лулзы и тупак.

Я уже приготовился собирать бинго.

Молодец. А теперь сделай так, чтобы программа, которая пытается осуществить доступ к mp_dict в обход мьютекса, упала в компайл-тайме.

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

Ну, это можно отнести даже к типу, например что такое проверка на if это когда машина выполняет для значения test инструкцию и в зависимости от этого делается jump или просто продолжает выполнение того что за ним. На уровне абстракций языка можно сказать что это тип, а его крайние значения определяют будет ли выполнена текущая инструкция jmp или нет. Так что в целом можно сказать что блокировка сама по себе это тип и вполне себе проверяемый на этапе разбора языка, но правда я всё равно не вкуриваю в то как оно может гарантированно проверить все случаи with _lock: это равносильно явной установке mutex_lock(m), его можно забыть вписать например, но вот если блок кода пометить выше типа _lock def(...)... тогда уже всё что входит в блок кода должно иметь проверку на блокирвоки внутри и правильную проверку на них или проверятся рантаймом, ты просто вызываешь функцию (кусок кода, байткода, инстуркуий, пофиг чего), а запустится она автоматически тогда когда блокировка будет отпущена и автоматически блокировка будет установлена, то есть в целом ненужно ничего явно указывать, нужно просто сказать что весь этот кусок кода помечен как блокирующий, не явным вызовом блокировки внутри ака семафор, а неявной блокировкой на уровне исполнения котрая гарантирует что хоть ты там навызывайся кого хочшеь в каком угодно порядке выполнено будет всё в порядке очереди захвата блокировки и никак иначе. Но тут типизация уже не на уровне куска памяти в оперативке, а на уровне куска кода.

Но тут типизация уже не на уровне куска памяти в оперативке

Да нет никакой типизации: есть лишь байты, которые группируются в какие-то структуры… Все 8-битное число, и даже небо, и даже… Не понимаю всех этих пространных рассуждений ряяя

Да with - это сахарок над явным вызовАми _lock.acquire и _lock.release, там аналог такого:

_lock.acquire()
try:
  # <код внутри with>
finally:
  _lock.release()

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

Но ты про скриптуху там в рантайме что угодно делать можно, а вот для статических языков это другое, тут тоже самое надо выразить и чтобы работало без рантайма и вирутальной машины, ну или с микрорантайм вставками в исполняемый код который отвечает за всё это вот. Есть же pragma omp parallel OpenMP параллелит код, сама ставит блокировки и гарантирует что всё будет ок. Но это уже другое.

А что мешает прогнать через статический анализатор программу на динамически типизированном языке?

И какой результат ты ожидаешь от такого прогона?

«Программа НАВЕРНОЕ правильная»?

Что существуют пути исполнения кода когда в функцию будет передан не тот тип

А если статический анализатор не нашел таких путей исполнения кода, то какое из двух утверждений верно?

• Таких путей нет.
• Они есть, но анализатор их не нашел.

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

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

не лохматить бабушку, а просто сразу писать на подходящем языке

Ещё можно пользоваться удобным инструментом получая плюшки статической типизации

Мир не идеален.

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

А потом ты читаешь новость про уязвимость в xz приводящую к атаке на sshd

А потом в огороде бузина цветёт.

Шо, сынку, помогла тебе статическая типизация от патчинга в рантайме?

Бинго собирается постепенно. Продолжайте.

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

Не понимаю, как это сделать в языке со статической типизацией без метапрограммирования (макросов). Можно код показать?

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

А теперь сделай так, чтобы программа, которая пытается осуществить доступ к mp_dict в обход мьютекса, упала в компайл-тайме.

Я не думаю что это возможно в принципе, без ложных срабатываний как ту так и в другую сторону. Runtime sanitizing - всё что остаётся.

Я не думаю что это возможно в принципе

В питоне? Да, невозможно.

В питоне? Да, невозможно.

Да нигде невозможно. Точнее - я с ходу не могу придумать насколько кастрированным должен быть язык чтобы все relevant runtime branches были (а) вИдимы в точках доступа к разделяемому ресурсу, (б) поддающимися статическому анализу.

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

правильно: имеется сущность обладающая интерфейсом. В интерфейсе есть атомарные операции и транзакционные. Мьютекс, это всё-таки уровнем ниже чем то что ТС пытается обсудить.

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

PS/ ну и типизация тут конечно-же непричём

Попробуй думать в терминах областей видимости, а не анализа путей исполнения, и задача становится решаемой.

Мьютекс, это всё-таки уровнем ниже чем то что ТС пытается обсудить.

В жизни нередко так и идёт – мы знаем детали реализации, а теперь нужно придумать для неё надежный интерфейс.

PS/ ну и типизация тут конечно-же непричём

Как это не при чём?

Тип данных характеризует набор операций, применимых к данному типу.

Ну, копай в сторону алгебраических эффектов. Там такое легко делается.

Попробуй думать в терминах областей видимости … и задача становится решаемой.

Позволю себе не согласиться: (а) я не хочу платить за мьютекс там где логика такова что я и так знаю что я «единственный», (б) не забываем про указатели и ссылки, (в) не забываем про атомарность (не факт что можно отпускать мьютекс в середине операции / транзакции).

сделай так, чтобы программа, которая пытается осуществить доступ к mp_dict в обход мьютекса, упала в компайл-тайме

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

В рантайме и кидай исключения, если мьютекс не захвачен, или типа того.

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

не забываем про указатели и ссылки

Для этого сырые указатели сначала нужно как-то получить.

Откуда иначе компилятору знать, какие значения ты передашь в свою функцию в рантайме?

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

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

Я думаю что мне хватит одного boolean’а переданного извне чтобы развалить любой статический анализатор который Вы можете придумать, максимум - двух.

Можно начать с этого:

void Foo::foo()
{
    bar(); /* compile-time error */
    {
        LockedContext lck = lock();
        lck.bar(); /* compilation successful */
    }
    bar(); /* compile-time error */
    lck->bar(); /* compile-time error */
}

Разваливайте.

Разваливайте

Здесь нет ничего передающегося извне.

Можно начать с этого

(Псевдокод):

void foo(bool b)
{
   std::optional<lock> lock;
   if (b)
      lock.reset(mutex);

   do_something_with_shared_resource();
}

Анализируйте :)

Если у тебя такие условия, то твой дизайн - говно, чини архитектуру. В любом случае выглядит надуманным и ненужным.

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

В программе имеются мьютексы m1, m2… mN.

Если у тебя все мютексы статические то там скорее всего и так всё тривиально. А вот более реальная ситуация: есть экземпляр структуры A, в ней есть мютекс, и есть экземпляр структуры B, на которую есть ссылка из структуры A, и в нём тоже есть мютекс. Надо, чтобы мютекс структуры A не пытался блокированно лочиться во время того как залочен мютекс хотя бы одной из структур B, на которые есть ссылки из A. Как ты это формализуешь в коде? Ну, может быть и сможешь, но там будет write-only ужас.

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

Я сейчас разгребаю модуль, где работа под мьютексом и без, написана как винегрет. Было бы очень актуально в моменте.

Может быть там просто оптимизированный код который ты не осилил?

Вот смотри например:

t_item * _find_item(t_list *list, char const *name, int lock) {
  t_item *item;
  mutex_lock(&list->mtx);
  item = find_item_locked(list, name);
  if(lock) mutex_lock(&item->mtx);
  mutex_unlock(&list->mtx);
  return item;
}

#define get_item(list,name) _find_item(list,name,1)
#define item_exists(list,name) (!!_find_item(list,name,0))