Ты не можешь обну ассемблерную команду нептомарно выполнить

И перед некоторыми x86 командами можно префикс lock ставить, что как-бы несколько намекает на то, что команды не особо атомарно выполняются.

И перед некоторыми x86 командами можно префикс lock ставить, что как-бы несколько намекает на то, что команды не особо атомарно выполняются.

Ну inc по спеке атомарный

И перед некоторыми x86 командами можно префикс lock ставить, что как-бы несколько намекает на то, что команды не особо атомарно выполняются.

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

Ну inc по спеке атомарный

даже для значения в памяти?

Да

хм

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

Что значит корректно, но логически неверно? То что я инкрементом 5 получу 6, это понятно. А вот то, что я из нескольких потоков проинкрементирую 5 пару раз и могу получить 6 - это уже как-то не особо хорошо. Это имелось ввиду?

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

Данные иногда бились

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

Скажем NullPointerException генерирует панику еще лучше )) Фишка в том, как без паник выдать правильный результат и не писать 100500 строк кода. Потому что на практике их никто не пишет. А Option[...] дает вариант удобно обрабатывать все нулевые значения не нагадив в код.

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

Нельзя инкрементить один и тот же регистр из нескольких потоков.

Я про память

отучаемся говорить за весь интернет

И заодно начинаем читать смайлы)) Кроме того, что понятие "дефолтный гошник" такое же абстрактное как "сферический конь" поэтому ни к кому конкретно относиться не может

Я про память

Тогда что значит "заинкрементятся корректно, но может быть гонка данных"? Как это понимать?

Заинкрементятся = данные не побьются. Со сложной структурой данные будут биться - часть полей будет из одного потока, часть из другого

Что значит данные не побьются? Если n потоков сделают обычный инкремент одного и того же значения памяти, может ли после этого оказаться в памяти число отличное от исходного + n?

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

Я что-то спрашивал про сложную структуру? То что число остаётся числом это и ежу понятно. Вопрос лишь в том, будет ли это корректное число?

Кароч почитай какую-нибудь книжку, статью про многопоточное прогрпммирование на си. Там все ньюнсы разжеваны

Просто инкремент значения в памяти - это чтение из памяти, сам инкремент, запись в память, то есть гипотетически это не атомарная операция, потому что другое ядро может между чтением и записью сделать своё чтение и запись и записать фактически неверное значение.

Кароч почитай какую-нибудь книжку, статью про многопоточное прогрпммирование на си. Там все ньюнсы разжеваны

Причём тут Си. Если я спрашиваю фактически про самый-самый низкий уровень? То что происходит в недрах процессора.

Просто инкремент значения в памяти - это чтение из памяти, сам инкремент, запись в память, то есть гипотетически это не атомарная операция, потому что другое ядро может между чтением и записью сделать своё чтение и запись и записать фактически неверное значение.

Ну вообще инкремент это немного другая операция

Просто инкремент значения в памяти - это чтение из памяти, сам инкремент, запись в память, то есть гипотетически это не атомарная операция, потому что другое ядро может между чтением и записью сделать своё чтение и запись и записать фактически неверное значение.

Нет, это одна операция и она атомарна

Именно ассемблерный inc

Нет, это одна операция и она атомарна

На уровне нескомпилированного кода x86

Просто переменная в твоем коде - уже нет

Именно ассемблерный inc

ассемблерный inc - это inc [eax] и атомарности то как раз тут и нет

потому что команда одна, а фактически операций сразу три

насколько я знаю, процессор не будет прерывать на середине выполнение команды inc [eax], но это не особо гарантирует её атомарность, потому что у нас скорее всего есть другие ядра или процессоры, которые могут выполнить свой inc [eax] одновременно для той же ячейки памяти

потому что команда одна, а фактически операций сразу три

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

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

На всех ядрах сразу? Ещё и для всех кэшей консистентность обеспечивает?

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

На всех ядрах сразу? Ещё и для всех кэшей консистентность обеспечивает?

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

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

Тут костыли x86 как раз и не причём.

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

На всех ядрах сразу? Ещё и для всех кэшей консистентность обеспечивает?

Не прав был, но если использовать lock, то атомарно выполнится.

Не прав был, но если использовать lock, то атомарно выполнится.

Так с этим то я как раз и не спорю

Тут костыли x86 как раз и не причём.

Тут не при чем, но в целом поддержка инструкций x86 требует кучи костылей.

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

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

Да и само наличие явного lock префикса как бы намекает.

Тут не при чем, но в целом поддержка инструкций x86 требует кучи костылей.

Ну так с этим вроде никто и не спорит.

В общем используйте атомики и спите спокойно. )

В общем используйте атомики и спите спокойно. )

используйте sync.Pool и радуйтесь :)

используйте sync.Pool и радуйтесь :)

Инкременты в туда пихать? ? Хм.

Инкременты в туда пихать? ? Хм.

нет, инкременты можно в атомик

Атомик в пул, пул в мютексы, а мютексы в уайтгруп. ?

Для надёжности.

Пишите однопоточный код и волосы будут послушными и шелковистыми

Пишите однопоточный код и волосы будут послушными и шелковистыми

Это кстати вполне возможно

Всем привет! каким образом можно брать параметры query из url и формы без конфликтов r.URL.Query().Get("date") r.PostFormValue("date") проблема в том, что они перекрывают друг друга, хотя мне нужно брать один и тот же параметр или через url или форму, чтобы сделать запрос в БД

Всем привет! каким образом можно брать параметры query из url и формы без конфликтов r.URL.Query().Get("date") r.PostFormValue("date") проблема в том, что они перекрывают друг друга, хотя мне нужно брать один и тот же параметр или через url или форму, чтобы сделать запрос в БД

что значит перекрывают?

Видимо имеются в виду, что данные могут поступать через body или query (post/get)

да

верно

ну а проверять просто и то и другое нельзя?

то есть не пойму как фронт прописать так, чтобы можно было параметры прописать в url а потом через r.URL.Query().Get("date") получить параметры

эээ

всё ещё не могу понять в чем вопрос

передаем в URL, ну ок, передавайте

Это кстати вполне возможно

только GO не нужен

то есть не пойму как фронт прописать так, чтобы можно было параметры прописать в url а потом через r.URL.Query().Get("date") получить параметры

Вступая на территорию Web учите основы https://webgyry.info/http-zapros-metodom-get

Кто знает каким образом так оптимизировали?

https://gist.github.com/311169ef04e27fe469ca91859af9cdff

https://gist.github.com/311169ef04e27fe469ca91859af9cdff

Это бенч 1.0 го и 1.11.

Это бенч 1.0 го и 1.11.

Спасибо, кеп.

Поэтому ваш вопрос видимо к разрабам языка.

Потому же почему нельзя было запилить сразу генерики или алгебраические типы — авторы языка слишком узколобы.

утверждать что авторы го не впилили в язык генерики потому-что "они на это не способны" это мягко говоря неправильно

утверждать что авторы го не впилили в язык генерики потому-что "они на это не способны" это мягко говоря неправильно

Да нет, правильно.

Что-то в последнее время тут спор не о чем.

Да нет, правильно.

они впилили генерики, встроенные и интерфейсные посчитав что этого вполне достаточно для решения их задач (Go во первых они делали для себя и для Google). Это решение было осознанным и обоснованным (ради уменьшения сложности языка) хорошо ли это действительно или нет? это уже другой вопрос, на который у меня наверное только очень поверхностный ответ: я не знаю, ни в том, ни в обратном не уверен)) traits в Rust'е на самом деле выглядят очень интересно, гораздо лучше C++ шаблонов а от C++ генериков у меня жилудочное наружу просится

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

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

Сгенерированный код от синтаксической реализации особо не зависит.

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

и как при этом не превратить Go в ещё один большой сложный язык))

Сгенерированный код от синтаксической реализации особо не зависит.

Не в синтаксисе проблема, точнее не только в нём

и как при этом не превратить Go в ещё один большой сложный язык))

Берёшь и не превращаешь, делов то.

помню как-то в интервью Пайк сказал "зачастую в языке столько возможностей решения проблемы, что ты больше времени тратишь на размышление того какие инструменты применить, чем на написание кода. Go должен иметь только 1 путь решения проблемы для повышения продуктивности" и в этих словах есть смысл учитывая что Go разрабатывался скорее не как "general purpose programming language" а скорее как "cloud infrastructure and application programming language"

мне кажется проблема в том, что люди слишком сильно хотят видить Go именно как "gen. purpose programming lang.", хотя он изначально для этого не изобретался

вобщем - классика)

но и это желание вполне оправдано. Ведь Go показал что способен на большее чем просто серверный ПО клепать

Берёшь и не превращаешь, делов то.

как у вас на словах всё просто)) сделали бы уже форк языка, запилили свой proposal генериков, предложили бы pull, делов то))

мне кажется проблема в том, что люди слишком сильно хотят видить Go именно как "gen. purpose programming lang.", хотя он изначально для этого не изобретался

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

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

по сути людям нужен некий Rust с GC ? щутка

RefCell и прочие техники GC уже есть в Rust, наверняка какая-нибудь #(feature) появится для GC. Врядли гибкость, многообразие функций и ругательств компилятора появятся в Go

по сути людям нужен некий Rust с GC ? щутка

Хотя я лично хотел бы язык с простым ООП, нравится мне оно. Но многие тут боятся ООП как огня.

RefCell и прочие техники GC уже есть в Rust, наверняка какая-нибудь #(feature) появится для GC. Врядли гибкость, многообразие функций и ругательств компилятора появятся в Go

RefCell?

RefCell?

Box, RefCell... Там куча вариантов, я давно не ржавел)

Хотя я лично хотел бы язык с простым ООП, нравится мне оно. Но многие тут боятся ООП как огня.

понятие ООП настолько размыто что люди сами не понимают чего боятся... боятся люди скорее наследования, а не OOP

Мне нравится наследование. ?

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

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

Потенциально?

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

Не видал

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

И?

вот без encapsulation жить сложно, это значительная часть OOP, её бояться не стоит