Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Пул потоков
|
|||
|---|---|---|---|
|
#18+
Написал простенький пул, и оказалось что работает он медленнее, чем если бы напрямую запустить выполнение задачи. Просмотрев результаты MONLBL обнаружил, что блокировка глобала (заменяет мютекс, т.к. иного не обнаружил в cache) - самая ресурсоемкая операция. Чем можно заменить виндовый мютекс в cache? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Исходник: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2009, 10:46 |
|
||
|
Пул потоков
|
|||
|---|---|---|---|
|
#18+
А если сделать так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. AddTask(Task) вместо Код: plaintext 1. Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2009, 09:33 |
|
||
|
Пул потоков
|
|||
|---|---|---|---|
|
#18+
Код: plaintext Попробуйте изменять это значение на LOW или NORMAL. Либо можете динамически менять приоритет, например: Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2009, 15:51 |
|
||
|
Пул потоков
|
|||
|---|---|---|---|
|
#18+
MaWr Ваш пример, к сожалению, некорректно,на мой взгляд, работает в месте: Код: plaintext 1. В то время, когда TaskNum получен, очередь не заблокирована, и другой поток может в этот момент принять ту же самую задачу кстати что и показало тестирование, в логе есть сообщения типа ThreadId=2344 Task=1 ThreadId=244 Task=1 ThreadId=8456 Task=1 Задача обрабатывается только один раз. Turk Пробовал как Вы сказали, результат даже хуже (по времени обработки). Может отказаться от очереди задач? т.е. для каждого потока будет свой узел глобала и при старте потоков блокировать этот узел. в WaitTask поставить ожидание разблокировки узла (для каждого потока свой узел). получится что то типа Код: plaintext 1. 2. 3. 4. 5. 6. Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2009, 19:02 |
|
||
|
Пул потоков
|
|||
|---|---|---|---|
|
#18+
Leron MaWr Ваш пример, к сожалению, некорректно,на мой взгляд, работает в месте: Код: plaintext 1. В то время, когда TaskNum получен, очередь не заблокирована, и другой поток может в этот момент принять ту же самую задачу кстати что и показало тестирование, в логе есть сообщения типа ThreadId=2344 Task=1 ThreadId=244 Task=1 ThreadId=8456 Task=1 Задача обрабатывается только один раз. После получения TaskNum в моем варианте происходит блокирование Код: plaintext Идея моего подхода заключается в использовании блокировки со временем ожидания 0, в отличие от Вашей бесконечной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2009, 14:34 |
|
||
|
Пул потоков
|
|||
|---|---|---|---|
|
#18+
Leron Turk Пробовал как Вы сказали, результат даже хуже (по времени обработки). Странно. Так как снижение нагрузки с 10 высокоприоритетных потоков обработки с повышение нагрузки одного потока формирования очереди должно было как-то позитивно отразиться. Пробовали все возможные варианты? Динамическое изменение приоритета тоже требует определенных временных затрат, поэтому скорее вариант со статическим приоритетом будет эффективнее. Большое число потоков отработки тоже может играть отрицательную роль (если только у вас не 10+ ядер). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2009, 17:48 |
|
||
|
Пул потоков
|
|||
|---|---|---|---|
|
#18+
MaWr , извеняюсь, я поторопился, когда протестировал то что Вы предложили и не особо разбираясь, почему неправильно работает пул. Ваша идея ожидания с таймаутом правильная, но ошибка в другом - допустим в очереди 10 задач (максимум тоже 10) с номерами 1..10, значение $$$jobpool("taskCount") тоже 10, добавляем новую задачу(AddTask), в AddTask ждем пока размер очереди станет <10, в этот момент задача под №1 ушла из очереди, установив счетчик $$$jobpool("taskCount") в 9, в AddTask: установим счетчик $$$jobpool("taskCount") в 10, добавляем новую задачу на позицию 10 (в Вашем варианте) поверх старой задачи, а ведь под №10 уже была задача, и на обработку она никогда не поступит. Вот так будут теряться задачи, ну а почему потоки получали одинаковые задачи, я так и не понял... Turk , попробуйте протестируйте, исходник вполне компилится (если убрать вызовы Date^DateFunc) вот Исходник: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2009, 15:06 |
|
||
|
Пул потоков
|
|||
|---|---|---|---|
|
#18+
AddTask(): Убираем блокировку на очереди, т.к. здесь мы не работает с существующими заданиями, а только добавляем новое (по уникальному индексу TaskCountAll). Блокировка на TaskCount нужна только в том случае, если AddTask() может вызываться из различных потоков. При одном потоке (наш пример) блокировку можно закомментировать. Получаем след. код: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. WaitTask(): В предложенном варианте с нулевой блокировкой проблема была в том, что одно задание могло попасть на обработку нескольким потокам, т.к. $order проходили все и после блокировки текущий элемент очереди не проверялся на существование. (Например, 2 потока прошли $order, потом 1й поток заблокировал элемент, удалил его из очереди и разблокировал его. Потом 2й поток успешно повторяет действия 1го, хотя на самом деле этого элемента уже нет в очереди.) Блокировка на TaskCount здесь не нужна, т.к. декремент ничего плохо не сделает для проверки в AddTask(). Получаем след. код: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. Про динамическое изменение приоритета для потоков обработки я уже писал выше. Лучше оставлять все потоки на среднем приоритете, а производительности добиваться за счет оптимизации алгоритма. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2009, 14:54 |
|
||
|
|

start [/forum/topic.php?fid=39&msg=35935211&tid=1558514]: |
0ms |
get settings: |
8ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
179ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
66ms |
get tp. blocked users: |
2ms |
| others: | 260ms |
| total: | 560ms |

| 0 / 0 |
