вполне можно и обойтись))
- пишите код в одном потоке. Не переживайте, компьютер успеет))
- не расшаривайте один ресурс на несколько потоков сразу
- дробите или копируйте ресурс
- "высокий параллелизм - это компромиссы"
авторТак чем же придется пожертвовать при использовании стратегии высокого параллелизма? В зависимости от дизайна приложения, вам, возможно, придется выполнять операции чтения вне транзакций, даже когда операция чтения выполняется в целях изменения данных. «Минуточку!» – скажете вы: «Так нельзя – это может кончиться изменением данных, которые уже были изменены после их чтения!» Это правильное замечание, и заодно – это точка старта игры в компромиссы. При этой стратегии, поскольку вы не удерживаете блокировок данных на чтение, шансы на получение исключений, говорящих об устаревших данных, при операциях обновления увеличивается. Однако, как и в случае корабля Vasa, придется выбирать, какие характеристики важнее: надежная, пуленепробиваемая транзакционная стратегия (типа стратегии слоя API) или высокий параллелизм и пропускная способность. В ситуациях с большим количеством параллельных обращений очень трудно обеспечить и то, и другое, а если попытаться достичь этого, может оказаться, что приложение не делает хорошо ни того, ни другого.
http://www.k-press.ru/cs/2009/3/ts/ts.asp

rdb_dev,
"Для того чтобы судить о качестве приготовленной яичницы - необязательно уметь нести яйца" (с)

Ну прочитал Войну и Мир за 3 сек. А дальше то что? Горд очень этим?
Бизнесу не надо читать на скорость (с)


Статью мою по ссылке про ПАРАЛЛЕЛИЗМ прочитал?
К компромиссам готов?

бабушкин зайчик,

блокировки в веб проектах это плохой стиль архитектуры.
Верить или нет - твоё дело.

вроде есть правило для студентов чтобы не висело))))
- поток с ГУИ без длительных операций.
Теперь скажи - как чтение Война и Мир за 3 сек в доп потоке потребовали блокировки?
))))
Какие то студенческие ТЗ для размышлений.
Нам надо вас уговаривать на блокировки?