История изменений
Исправление Manhunt, (текущая версия) :
Средствами доставки запросов на чтение/запись данных, самих данных для записи и подтверждений об успешности выполнения действий могут быть трубы, очереди сообщений и даже файлы. Суть в том, что в «службохранительном» подходе потокам не нужно драться и тратить свои вычислительные мощности за право получить обслуживание. Это не переизобретение семафора или мьютекса, как тут пишут форумчане выше, это отложенный вид обслуживания по предварительному запросу.
Такая архитектура имеет право на жизнь для определенного круга задач. Однако в общем случае она может работать не эффективно, поскольку:
1. Однопоточный диспетчер будет «бутылочным горлышком», т.е. будет раздавать свои ответы клиентам не достаточно быстро для того, чтобы те смогли полностью утилизировать все ядра;
2. Велики накладные расходы на сложное взаимодействие с диспетчером. Клиент должен разместить запрос у диспетчера, переключиться на другую работу пока ответ на запрос не готов, следить за готовностью ответа, вернуться к старой работе когда ответ созреет. А таких отложенных запросов может быть не 1 а 100, надо где-то помнить клиентский контекст для них всех, тратить ресурсы на управление им;
3. Latency также далека от идеала (если важен не только throughput);
драться и тратить свои вычислительные мощности за право получить обслуживание
Аналогия с дракой применима в основном только к spinlock. В остальных случаях поток, если нужный ресурс занят, не дерётся и не тратит ресурсы, а засыпает.
Исправление Manhunt, :
Средствами доставки запросов на чтение/запись данных, самих данных для записи и подтверждений об успешности выполнения действий могут быть трубы, очереди сообщений и даже файлы. Суть в том, что в «службохранительном» подходе потокам не нужно драться и тратить свои вычислительные мощности за право получить обслуживание. Это не переизобретение семафора или мьютекса, как тут пишут форумчане выше, это отложенный вид обслуживания по предварительному запросу.
Такая архитектура имеет право на жизнь для определенного круга задач. Однако в общем случае она может работать не эффективно, поскольку:
1. Однопоточный диспетчер будет «бутылочным горлышком», т.е. будет раздавать свои ответы клиентам не достаточно быстро для того, чтобы те смогли полностью утилизировать все ядра;
2. Велики накладные расходы на сложное взаимодействие с диспетчером. Клиент должен разместить запрос у диспетчера, переключиться на другую работу пока ответ на запрос не готов, следить за готовностью ответа, вернуться к старой работе когда ответ созреет. А таких отложенных запросов может быть не 1 а 100, надо где-то помнить клиентский контекст для них всех, тратить ресурсы на управление им;
3. Latency также далека от идеала (если важен не только throughput);
И что с дедлоками? Например, у нас клиент1 получил ресурс A от диспетчера, параллельно ему клиент2 получил ресурс B от диспетчера. Теперь клиенту1 понадобился ресурс B, а клиенту2 понадобится ресурс A. Оба они обратились к диспетчеру, и для продолжения работы им нужен запрошенный ресурс. Когда они его получат? (Никогда). То есть выходит, что диспетчер вовсе не обеспечивает своим клиентам беззаботной жизни, надо по-прежнему внимательно следить за руками.
драться и тратить свои вычислительные мощности за право получить обслуживание
Аналогия с дракой применима в основном только к spinlock. В остальных случаях поток, если нужный ресурс занят, не дерётся и не тратит ресурсы, а засыпает.
Исправление Manhunt, :
Средствами доставки запросов на чтение/запись данных, самих данных для записи и подтверждений об успешности выполнения действий могут быть трубы, очереди сообщений и даже файлы. Суть в том, что в «службохранительном» подходе потокам не нужно драться и тратить свои вычислительные мощности за право получить обслуживание. Это не переизобретение семафора или мьютекса, как тут пишут форумчане выше, это отложенный вид обслуживания по предварительному запросу.
Такая архитектура имеет право на жизнь для определенного круга задач. Однако в общем случае она может работать не эффективно, поскольку:
1. Однопоточный диспетчер будет «бутылочным горлышком», т.е. будет раздавать свои ответы клиентам не достаточно быстро для того, чтобы те смогли полностью утилизировать все ядра;
2. Велики накладные расходы на сложное взаимодействие с диспетчером. Клиент должен разместить запрос у диспетчера, переключиться на другую работу пока ответ на запрос не готов, следить за готовностью ответа, вернуться к старой работе когда ответ созреет. А таких отложенных запросов может быть не 1 а 100, надо где-то помнить клиентский контекст для них всех, тратить ресурсы на управление им;
3. Latency также далека от идеала (если важен не только throughput);
4. Что с дедлоками? Например, у нас клиент1 получил ресурс A от диспетчера, параллельно ему клиент2 получил ресурс B от диспетчера. Теперь клиенту1 понадобился ресурс B, а клиенту2 понадобится ресурс A. Оба они обратились к диспетчеру, и для продолжения работы им нужен запрошенный ресурс. Когда они его получат? (Никогда). То есть выходит, что диспетчер вовсе не обеспечивает своим клиентам беззаботной жизни, надо по-прежнему внимательно следить за руками.
драться и тратить свои вычислительные мощности за право получить обслуживание
Аналогия с дракой применима в основном только к spinlock. В остальных случаях поток, если нужный ресурс занят, не дерётся и не тратит ресурсы, а засыпает.
Исправление Manhunt, :
Средствами доставки запросов на чтение/запись данных, самих данных для записи и подтверждений об успешности выполнения действий могут быть трубы, очереди сообщений и даже файлы. Суть в том, что в «службохранительном» подходе потокам не нужно драться и тратить свои вычислительные мощности за право получить обслуживание. Это не переизобретение семафора или мьютекса, как тут пишут форумчане выше, это отложенный вид обслуживания по предварительному запросу.
Такая архитектура имеет право на жизнь для определенного круга задач. Однако в общем случае она может работать не эффективно, поскольку:
1. Однопоточный диспетчер будет «бутылочным горлышком», т.е. будет раздавать свои ответы клиентам не достаточно быстро для того, чтобы те смогли полностью утилизировать все ядра;
2. Велики накладные расходы на сложное взаимодействие с диспетчером. Клиент должен разместить запрос у диспетчера, переключиться на другую работу пока ответ на запрос не готов, следить за готовностью ответа, вернуться к старой работе когда ответ созреет. А таких отложенных запросов может быть не 1 а 100, надо где-то помнить клиентский контекст для них всех, тратить ресурсы на управление им;
3. Latency также далека от идеала (если важен не только throughput);
4. Что с дедлоками? Например, у нас клиент1 получил ресурс A от диспетчера, параллельно ему клиент2 получил ресурс B от диспетчера. Теперь клиенту1 понадобился ресурс B, а клиенту2 понадобится ресурс A. Оба они обратились к диспетчеру, и для продолжения работы им нужен запрошенный ресурс. Когда они его получат?
драться и тратить свои вычислительные мощности за право получить обслуживание
Аналогия с дракой применима в основном только к spinlock. В остальных случаях поток, если нужный ресурс занят, не дерётся и не тратит ресурсы, а засыпает.
Исправление Manhunt, :
Средствами доставки запросов на чтение/запись данных, самих данных для записи и подтверждений об успешности выполнения действий могут быть трубы, очереди сообщений и даже файлы. Суть в том, что в «службохранительном» подходе потокам не нужно драться и тратить свои вычислительные мощности за право получить обслуживание. Это не переизобретение семафора или мьютекса, как тут пишут форумчане выше, это отложенный вид обслуживания по предварительному запросу.
Такая архитектура имеет право на жизнь для определенного круга задач. Однако в общем случае она может работать не эффективно, поскольку:
1. Однопоточный диспетчер будет «бутылочным горлышком», т.е. будет раздавать свои ответы клиентам не достаточно быстро для того, чтобы те смогли полностью утилизировать все ядра;
2. Велики накладные расходы на сложное взаимодействие с диспетчером. Клиент должен разместить запрос у диспетчера, переключиться на другую работу пока ответ на запрос не готов, следить за готовностью ответа, вернуться к старой работе когда ответ созреет. А таких отложенных запросов может быть не 1 а 100, надо где-то помнить клиентский контекст для них всех, тратить ресурсы на управление им;
3. Latency также далека от идеала (если важен не только throughput);
4. Что с дедлоками? Например, у нас клиент1 получил ресурс A от диспетчера, параллельно ему клиент2 получил ресурс B от диспетчера. Теперь клиенту1 понадобился ресурс B, а клиенту2 понадобится ресурс A. Оба они обратились к диспетчеру, и для продолжения работы им нужен ответ от диспетчера. Когда они его получат?
драться и тратить свои вычислительные мощности за право получить обслуживание
Аналогия с дракой применима в основном только к spinlock. В остальных случаях поток, если нужный ресурс занят, не дерётся и не тратит ресурсы, а засыпает.
Исправление Manhunt, :
Средствами доставки запросов на чтение/запись данных, самих данных для записи и подтверждений об успешности выполнения действий могут быть трубы, очереди сообщений и даже файлы. Суть в том, что в «службохранительном» подходе потокам не нужно драться и тратить свои вычислительные мощности за право получить обслуживание. Это не переизобретение семафора или мьютекса, как тут пишут форумчане выше, это отложенный вид обслуживания по предварительному запросу.
Такая архитектура имеет право на жизнь для определенного круга задач. Однако в общем случае она может работать не эффективно, поскольку:
1. Однопоточный диспетчер будет «бутылочным горлышком», т.е. будет раздавать свои ответы клиентам не достаточно быстро для того, чтобы те смогли полностью утилизировать все ядра;
2. Велики накладные расходы на сложное взаимодействие с диспетчером. Клиент должен разместить запрос у диспетчера, переключиться на другую работу пока ответ на запрос не готов, следить за готовностью ответа, вернуться к старой работе когда ответ созреет. А таких отложенных запросов может быть не 1 а 100, надо где-то помнить клиентский контекст для них всех, тратить ресурсы на управление им;
3. Latency также далека от идеала (если важен не только throughput);
4. Что с дедлоками? Например, у нас клиент1 получил ресурс A от диспетчера, параллельно ему клиент2 уже получил ресурс B от диспетчера. Теперь клиенту1 понадобился ресурс B, а клиенту2 понадобится ресурс A. Оба они обратились к диспетчеру, и для продолжения работы им нужен ответ от диспетчера. Когда они его получат?
драться и тратить свои вычислительные мощности за право получить обслуживание
Аналогия с дракой применима в основном только к spinlock. В остальных случаях поток, если нужный ресурс занят, не дерётся и не тратит ресурсы, а засыпает.
Исправление Manhunt, :
Средствами доставки запросов на чтение/запись данных, самих данных для записи и подтверждений об успешности выполнения действий могут быть трубы, очереди сообщений и даже файлы. Суть в том, что в «службохранительном» подходе потокам не нужно драться и тратить свои вычислительные мощности за право получить обслуживание. Это не переизобретение семафора или мьютекса, как тут пишут форумчане выше, это отложенный вид обслуживания по предварительному запросу.
Такая архитектура имеет право на жизнь для определенного круга задач. Однако в общем случае она может работать не эффективно, поскольку:
1. Однопоточный диспетчер будет «бутылочным горлышком», т.е. будет раздавать свои ответы клиентам не достаточно быстро для того, чтобы те смогли полностью утилизировать все ядра;
2. Велики накладные расходы на сложное взаимодействие с диспетчером. Клиент должен разместить запрос у диспетчера, переключиться на другую работу пока ответ на запрос не готов, следить за готовностью ответа, вернуться к старой работе когда ответ созреет. А таких отложенных запросов может быть не 1 а 100, надо где-то помнить клиентский контекст для них всех, тратить ресурсы на управление им;
3. Latency также далека от идеала (если важен не только throughput);
4. Что с дедлоками? Когда у нас клиент1 получил ресурс A от диспетчера, параллельно ему клиент2 уже получил ресурс B от диспетчера. Теперь клиенту1 понадобился ресурс B, а клиенту2 понадобится ресурс A. Оба они обратились к диспетчеру, и для продолжения работы им нужен ответ от диспетчера. Когда они его получат?
драться и тратить свои вычислительные мощности за право получить обслуживание
Аналогия с дракой применима в основном только к spinlock. В остальных случаях поток, если нужный ресурс занят, не дерётся и не тратит ресурсы, а засыпает.
Исправление Manhunt, :
Средствами доставки запросов на чтение/запись данных, самих данных для записи и подтверждений об успешности выполнения действий могут быть трубы, очереди сообщений и даже файлы. Суть в том, что в «службохранительном» подходе потокам не нужно драться и тратить свои вычислительные мощности за право получить обслуживание. Это не переизобретение семафора или мьютекса, как тут пишут форумчане выше, это отложенный вид обслуживания по предварительному запросу.
Такая архитектура имеет право на жизнь для определенного круга задач. Однако в общем случае она может работать не эффективно, поскольку:
1. Однопоточный диспетчер будет «бутылочным горлышком», т.е. будет раздавать свои ответы клиентам не достаточно быстро для того, чтобы те смогли полностью утилизировать все ядра;
2. Велики накладные расходы на сложное взаимодействие с диспетчером. Клиент должен разместить запрос у диспетчера, переключиться на другую работу пока ответ на запрос не готов, следить за готовностью ответа, вернуться к старой работе когда ответ созреет. А таких отложенных запросов может быть не 1 а 100, надо где-то помнить клиентский контекст для них всех, тратить ресурсы на управление им;
3. Latency также далека от идеала (если важен не только throughput).
драться и тратить свои вычислительные мощности за право получить обслуживание
Аналогия с дракой применима в основном только к spinlock. В остальных случаях поток, если нужный ресурс занят, не дерётся и не тратит ресурсы, а засыпает.
Исправление Manhunt, :
Средствами доставки запросов на чтение/запись данных, самих данных для записи и подтверждений об успешности выполнения действий могут быть трубы, очереди сообщений и даже файлы. Суть в том, что в «службохранительном» подходе потокам не нужно драться и тратить свои вычислительные мощности за право получить обслуживание. Это не переизобретение семафора или мьютекса, как тут пишут форумчане выше, это отложенный вид обслуживания по предварительному запросу.
Такая архитектура имеет право на жизнь для определенного круга задач. Однако в общем случае она может работать не эффективно, поскольку:
1. Однопоточный диспетчер будет «бутылочным горлышком», т.е. будет раздавать свои ответы клиентам не достаточно быстро для того, чтобы те смогли полностью утилизировать все ядра;
2. Велики накладные расходы на сложное взаимодействие с диспетчером. Клиент должен разместить запрос у диспетчера, переключиться на другую работу пока ответ на запрос не готов, следить за готовностью ответа, вернуться к старой работе когда ответ созреет. А таких отложенных запросов может быть не 1 а 100, надо где-то помнить клиентский контекст для них всех, уметь его переключать;
3. Latency также далека от идеала (если важен не только throughput).
драться и тратить свои вычислительные мощности за право получить обслуживание
Аналогия с дракой применима в основном только к spinlock. В остальных случаях поток, если нужный ресурс занят, не дерётся и не тратит ресурсы, а засыпает.
Исходная версия Manhunt, :
Средствами доставки запросов на чтение/запись данных, самих данных для записи и подтверждений об успешности выполнения действий могут быть трубы, очереди сообщений и даже файлы. Суть в том, что в «службохранительном» подходе потокам не нужно драться и тратить свои вычислительные мощности за право получить обслуживание. Это не переизобретение семафора или мьютекса, как тут пишут форумчане выше, это отложенный вид обслуживания по предварительному запросу.
Такая архитектура имеет право на жизнь для определенного круга задач. Однако в общем случае она может работать не эффективно, поскольку:
1. Однопоточный диспетчер будет «бутылочным горлышком», т.е. не позволит остальным задачам полностью утилизировать все ядра;
2. Велики накладные расходы на сложное взаимодействие с диспетчером. Клиент должен разместить запрос у диспетчера, переключиться на другую работу пока ответ на запрос не готов, следить за готовностью ответа, вернуться к старой работе когда ответ созреет. А таких отложенных запросов может быть не 1 а 100, надо где-то помнить клиентский контекст для них всех, уметь его переключать;
3. Latency также далека от идеала (если важен не только throughput).
драться и тратить свои вычислительные мощности за право получить обслуживание
Аналогия с дракой применима в основном только к spinlock. В остальных случаях поток, если нужный ресурс занят, не дерётся и не тратит ресурсы, а засыпает.