type // simplified TMyLockableObject = class(TObject, ILockableObject); TMyLockableObject = class(TInterfacedObject, ILockableObject); var v : TMyLockableObject; ... v.Lock; try ..code.. v.prop := data; finally v.Unlock; end;
You also add the lock/unlock in setters and getters that may be used in contention situations. Normally not needed if - the v variable can't change via threading - the v.props are of integer size or less (ie atomic)
Sometimes you can use a fiber. ;-)
ReplyDeleteNo a thread is not good for everything, sometimes you need two threads!
ReplyDeleteLOL!
ReplyDeleteI hate the "thread optimization"!
That is SO annoying!
A
Ondrej Kelle unless you use fibers and IWebBrowser. IE's JavaScript engine does some nasty stack pointer tricks.
ReplyDeleteI think people should use MORE threads. It would demystify them, improve the tech used to implement them, and forever get rid of non-responding UX.
ReplyDeletemore processes, less threads..
ReplyDeleteinter process signalling is a lot more expensive and complex than inter thread signalling, though - melice huang
ReplyDeleteThreads start to shine when you thread many of them into a canvas.
ReplyDeletetype // simplified
ReplyDeleteTMyLockableObject = class(TObject, ILockableObject);
TMyLockableObject = class(TInterfacedObject, ILockableObject);
var
v : TMyLockableObject;
...
v.Lock;
try
..code..
v.prop := data;
finally
v.Unlock;
end;
You also add the lock/unlock in setters and getters that may be used in contention situations.
Normally not needed if
- the v variable can't change via threading
- the v.props are of integer size or less (ie atomic)
You are right. I actually prefer
ReplyDeleteTLockableObject = class(TInterfacedPersistent, ILockableObject)
Lars Fosdal bet you like it more cause you can use that in packages :)
ReplyDeleteA