Наши партнеры



Реклама
  • ИП Попов А.П.
  • ИНН: 602715631406
Диалог бабушки и внучки! Такое видео вызывает смех сквозь слезы…
Реклама
  • ИП Попов А.П.
  • ИНН: 602715631406
Танец на выпускном взорвал сеть: смотреть без детей
Реклама
  • ИП Попов А.П.
  • ИНН: 602715631406
Женатым лучше не смотреть: танец роскошной Татьяны (видео)
Реклама
  • ИП Попов А.П.
  • ИНН: 602715631406
Этот танец невесты оставит вас без слов! Пересмотрела 10 раз!
Реклама
  • ИП Попов А.П.
  • ИНН: 602715631406
Диалог бабушки и внучки! Такое видео вызывает смех сквозь слезы…



Книги по Linux (с отзывами читателей)

Библиотека сайта rus-linux.net

Реклама
  • ИП Попов А.П.
  • ИНН: 602715631406
Танец на выпускном взорвал сеть: смотреть без детей

What kinds of things should be threaded or multitasked?

    If you are a programmer and would like to take advantage of multithreading, the natural question is what parts of the program should/ should not be threaded. Here are a few rules of thumb (if you say "yes" to these, have fun!):

    • Are there groups of lengthy operations that don't necessarily depend on other processing (like painting a window, printing a document, responding to a mouse-click, calculating a spreadsheet column, signal handling, etc.)?
    • Will there be few locks on data (the amount of shared data is identifiable and "small")?
    • Are you prepared to worry about locking (mutually excluding data regions from other threads), deadlocks (a condition where two COEs have locked data that other is trying to get) and race conditions (a nasty, intractable problem where data is not locked properly and gets corrupted through threaded reads & writes)?
    • Could the task be broken into various "responsibilities"? E.g. Could one thread handle the signals, another handle GUI stuff, etc.?

[Left Arrow]
[Home]
[Book Search]
[Mailbox]
[Right Arrow]
[Previous Page] [First Page] [Dictionary] [Email Author] [Next Page]


Реклама
  • ИП Попов А.П.
  • ИНН: 602715631406
Этот танец невесты оставит вас без слов! Пересмотрела 10 раз!