Программирование[11]

Just.Doit написал 42 минуты назад:

определению асинхронная работа - это работа не в том же потоке управления

Какое-то фиговое ты определение дал, не? Классический вопрос для собеса: "отличие асинхронности от многопоточности". А у тебя и то и то в определение входит 

besteady написал 6 минут назад:

Классический вопрос для собеса: "отличие асинхронности от многопоточности".

И как на него отвечать предполагается

Vova написал 20 минут назад:

придумали разные reader-writer локи на случай если тебе они нужны

Для read лок не нужен пишут 

Я только алгоритмические задачи умею решать на собесах Больше ничего не умею

Vova написал 2 минуты назад:

besteady написал 9 минут назад:

Классический вопрос для собеса: "отличие асинхронности от многопоточности".

 

И как на него отвечать предполагается

А я не знаю 

Там где я это прочитал (хабро статья) ответа вроде не было.

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

besteady написал Только что:

Там где я это прочитал (хабро статья) ответа вроде не было.

Ахахаха гениально

besteady написал 7 минут назад:

Vova написал 28 минут назад:

придумали разные reader-writer локи на случай если тебе они нужны

Для read лок не нужен пишут 

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

besteady написал 1 минуту назад:

Vova написал 8 минут назад:

besteady написал 15 минут назад:

Классический вопрос для собеса: "отличие асинхронности от многопоточности".

 

И как на него отвечать предполагается

А я не знаю 

Там где я это прочитал (хабро статья) ответа вроде не было.

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

Асинхронное выполнение - когда ты не дожидаешься результата выполнения

Я имел ввиду это

https://man7.org/linux/man-pages/man2/flock.2.html

Grohuf написал 11 минут назад:

Асинхронное выполнение - когда ты не дожидаешься результата выполнения

Ну это коряво звучит

Отсутствие синхронизации лучше между выполнением задач лучше имхо 

Vova написал 17 минут назад:

Я имел ввиду это

 

https://man7.org/linux/man-pages/man2/flock.2.html

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

besteady написал 1 час назад:

Just.Doit написал 1 час назад:

определению асинхронная работа - это работа не в том же потоке управления

Какое-то фиговое ты определение дал, не? Классический вопрос для собеса: "отличие асинхронности от многопоточности". А у тебя и то и то в определение входит 

 

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

термина многопоточность в информатике/теории вычислений/CS вообще особо нет. это эдакий базворд обозанчающий что либо связанное с количеством потоков > 1
 

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

besteady написал 32 минуты назад:

Grohuf написал 45 минут назад:

Асинхронное выполнение - когда ты не дожидаешься результата выполнения

Ну это коряво звучит

Отсутствие синхронизации лучше между выполнением задач лучше имхо 

но у тебя может быть синхронизация между выполнением задач

ставишь лок и лочишься

от этого каждая отдельная задача асинхронной не перестает быть.

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

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

ты при этом можешь продолжить делать что-от еще, или отправить еще 100 таких вычислений. И затем ОЖИДАТЬ РЕЗУЛЬАТАТА выполнения этих асинхронных задач. а можешь не ждать. при этом ждешь ты или нет не влияет на определение асинхронности самих этих задач

Just.Doit написал 14 минут назад:

но у тебя может быть синхронизация между выполнением задач

ставишь лок и лочишься

от этого каждая отдельная задача асинхронной не перестает быть.

Если ты дожидаешься выполнения задачи, то это синхронное выполнение

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

и кстати если ты засабмитешь асинхронное вычесление, и потом сразу же повиснешь на блокирующем ожидании ее результата (через фьючу или подобный api) - это всеравно будет асинхронное вычисление. просто ты в потоке заблокировался на ожидание резульата. оно практически эквивалентно выполнению не асинхронно, но не совсем тк могут быть нюансы. потом что асинхронное вычисление может быть выполнено на другом треде, на другом тредпуле (например на блокинг пуле, или наоборот на CPU bound пуле, или на low priority пуле), а самое главное, ожидание на текущем треде может быть подвержено оптимизации с вытесняющей многозадачностью (долго объяснять что именно это может давать)

Grohuf написал 1 минуту назад:

Если ты дожидаешься выполнения задачи, то это синхронное выполнение

ноуп

Just.Doit написал 6 минут назад:

ноуп

"Вздыхает"

Ты понимаешь, что когда ты дергаешь какую-то синхронную функцию send() у какого-то модуля, то ты не можешь знать, выполняет он задачу на том же потоке, или на другом? Ты понимаешь, что асинхронно можно выполнить задачу на этом же потоке?

Grohuf написал 4 минуты назад:

Just.Doit написал 12 минут назад:

ноуп

"Вздыхает"

Ты понимаешь, что когда ты дергаешь какую-то синхронную функцию send() у какого-то модуля, то ты не можешь знать, выполняет он задачу на том же потоке, или на другом? Ты понимаешь, что асинхронно можно выполнить задачу на этом же потоке?

конечно понимаю

но речь то шла не об этом (опять)

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

у тебя есть что-то что принимает асинхронные вычисления на выполение - обозначим это методом "execAsync(thunk)", который возвращает future/promise результата

если ты тутже встанешь на ожидание этого future/promise, у тебя само вычисление, отправленное на асинхронное выполнение, от этого синхронным не станет. другими словами строчка "execAsync(thunk)" как запускала асинхронное вычисление, так и запускает его. НЕЗАВИСИМО ОТ ТОГО встанешь ты потом наожидание результата или нет.

Just.Doit написал 26 минут назад:

термина многопоточность в информатике/теории вычислений/CS вообще особо нет. это эдакий базворд обозанчающий что либо связанное с количеством потоков > 1

Ну это по идее и есть параллелизм. Мб я слово перепутал. Разве что parallelism судя по статье в вики в отличие от concurrent подразумевает несколько физических потоков, когда concurrent может быть виртуальной 

То есть это concurrent скорее

Grohuf написал 5 минут назад:

какую-то синхронную функцию send() у какого-то модуля, то ты не можешь знать, выполняет он задачу на том же потоке

ну кстати это не до конца корректное утверждение

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

Just.Doit написал 4 минуты назад:

Grohuf написал 12 минут назад:

какую-то синхронную функцию send() у какого-то модуля, то ты не можешь знать, выполняет он задачу на том же потоке

ну кстати это не до конца корректное утверждение

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

Тело может содержать только постановку задачи и ожидания ее выполнения

Just.Doit написал 5 минут назад:

Grohuf написал 9 минут назад:

Just.Doit написал 17 минут назад:

ноуп

"Вздыхает"

Ты понимаешь, что когда ты дергаешь какую-то синхронную функцию send() у какого-то модуля, то ты не можешь знать, выполняет он задачу на том же потоке, или на другом? Ты понимаешь, что асинхронно можно выполнить задачу на этом же потоке?

конечно понимаю

но речь то шла не об этом (опять)

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

 

у тебя есть что-то что принимает асинхронные вычисления на выполение - обозначим это методом "execAsync(thunk)", который возвращает future/promise результата

если ты тутже встанешь на ожидание этого future/promise, у тебя само вычисление, отправленное на асинхронное выполнение, от этого синхронным не станет. другими словами строчка "execAsync(thunk)" как запускала асинхронное вычисление, так и запускает его. НЕЗАВИСИМО ОТ ТОГО встанешь ты потом наожидание результата или нет.

 

 

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

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