Які помилкові ідеї існують, що відлякує людей за допомогою ниток? [зачинено]

Так, реально впровадити нитку в програму, але чому деякі люди не реалізуватимуть їх, навіть коли в цьому очевидна потреба.

Приклад: Програма повинна завантажити набір даних із бази даних, що потрібно зробити, це зробити з'єднання та отримати дані з бази даних у робочій нитці, а потім завантажити їх у графічний інтерфейс, залишаючи потік GUI відповідальним для користувача .

Але ні, я розмовляв з людьми, які, здається, думають, що нитки є злими і поганими, а що ні, і варто уникати їх за будь-яку ціну. Я навіть чув, що якийсь класний інструктор радив не використовувати теми, і тому не хотів покривати їх використання. ЩО???

Коли апаратне забезпечення переходить у багатоядерні, я думаю, що нам потрібно краще зрозуміти теми і не боятися їх використовувати. Я вважаю це захоплюючою темою особисто.

То які речі, які ви чули про нарізування, є хибними?

Нитки важкі

Звичайно. Це може бути. Однак люди отримують цю думку в голові, що це так важко, що вони не турбуються намагатися зрозуміти це.

Це не так, як неможливо.

Це не складна частина різьби, а необхідність синхронізації та всього іншого, що поставляється з використанням ниток. У вашому прикладі графічного інтерфейсу, як сказати головному потоку, до якого готовий доступ до набору даних? Ви обходите цілу купу зворотних дзвінків? Ви розкидаєте цілу купу контрольних змінних по всьому коду? У деяких моделях GUI, наприклад Silverlight, є щось, що називається спорідненість до потоку, що означає, що ви не можете отримати доступ до елементів GUI, що сидять на головній нитці, з інших потоків, тому вам доведеться виходити зі шляху, щоб головний потік знав певну інформацію. готовий до подальшої обробки.

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

Threading вирішує всі ваші проблеми

Якщо у вас виникають проблеми з продуктивністю, ви не повинні переходити до нитки.

Нитки легкі

Нитки легкі в десятках і двадцятих роках. Нерестують тисячі ниток це не так.

Нитка простий [Java]

Створити теми легко, це не означає, що ви отримаєте користь від цього.

Ви зрештою втратите будь-які надбавки від нанизування, тому що для виправлення шалених помилок, які виникнуть внаслідок використання деяких бібліотек / функцій, які не є безпечними для потоків (про що ви не знали), буде потрібна надмірна синхронізація.

У вас набагато більша ймовірність зустрітися з помилкою, яку ви не зможете виправити, якщо ви будете використовувати нитки, тоді, коли цього не зробите.

Підсумовуючи точку розуму, чому нитки важко використовувати: -
Справжні речі 1) Потрібна синхронізація та ретельні проектні рішення щодо того, що заблокувати та коли заблокувати
2) Немає контролю над потоком часу виконання
3) Складне налагодження
4) (Дуже мало часи) сумісність платформи: - Бібліотеки існують, щоб подбати про це

Неправдиві речі: -
1) Заплутані поняття безпечної для потоків та повторної функції
2) Нитки виглядають добре на папері, але їх дуже важко реалізувати

Якщо ви не хочете писати тести для свого коду, не використовуйте теми.

Нитки не призначені для типового програміста "копіювати та вставляти", який не розуміє основних основ ОС та комп'ютерної архітектури. Оскільки 90% програмістів знайомі лише з Java, це насправді не люди, яким слід користуватися потоками. Java робить потоки "легкими", але я бачив багато програмістів, які просто думають, що якщо вони будуть використовувати синхронізовані структури, їх код буде працювати в потоках .... ем ні.

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

Приклад: Програма повинна завантажити набір даних із бази даних, що потрібно зробити, це зробити з'єднання та отримати дані з бази даних у робочій нитці, а потім завантажити їх у графічний інтерфейс, залишаючи потік GUI відповідальним для користувача .

Я не бачу, що ця ситуація означає необхідність використання нарізки принаймні з 4 причин:

1. Пошук даних повинен бути дуже швидким.

2. У багатьох програмах «Лінійний бізнес» користувач не має нічого спільного з додатком за 1 секунду або дві, які він / вона чекає результату. Також користувачеві доведеться почекати, поки дані повернуться будь-яким способом, щоб виконати бажане завдання. З іншого боку, запит можна кодувати інтелектуально таким чином, що він одночасно отримує лише повну сторінку інформації, а інші методи оптимізації можуть допомогти в часі відповіді.

3. У веб-інтерфейсах посилання можуть бути активовані щодо моделі різьблення.

4. Тема додає складності, як ви визнаєте, деякі розробники внизу лінії можуть не мати змоги додати функції або налагодити складний код.

Моя думка: використовуйте нитку, коли потрібно, тому що технічна ремонтопридатність та надійність є більш цінними для організації, ніж елегантність коду.