Wrapper für WinAPI SRWLock, als Ersatz für TMultiReadExclusiveWriteSynchronizer.
msdn.microsoft.com/e...aa904937(VS.85).aspx
Man lese über die Einschränkungen auf MSDN, wenn man die akzeptieren kann ist das sicher eine effizientere Alternative zu TMultiReadExclusiveWriteSynchronizer.
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:
| unit SRWLock;
interface
type TSRWLock = class private FLock: Pointer; public procedure AcquireShared; procedure ReleaseShared; procedure AcquireExclusive; procedure ReleaseExclusive; end;
implementation
procedure AcquireSRWLockShared(var P: Pointer); stdcall; external 'kernel32.dll' name 'AcquireSRWLockShared'; procedure ReleaseSRWLockShared(var P: Pointer); stdcall; external 'kernel32.dll' name 'ReleaseSRWLockShared';
procedure AcquireSRWLockExclusive(var P: Pointer); stdcall; external 'kernel32.dll' name 'AcquireSRWLockExclusive'; procedure ReleaseSRWLockExclusive(var P: Pointer); stdcall; external 'kernel32.dll' name 'ReleaseSRWLockExclusive';
procedure TSRWLock.AcquireShared; begin AcquireSRWLockShared(FLock); end;
procedure TSRWLock.ReleaseShared; begin ReleaseSRWLockShared(FLock); end;
procedure TSRWLock.AcquireExclusive; begin AcquireSRWLockExclusive(FLock); end;
procedure TSRWLock.ReleaseExclusive; begin ReleaseSRWLockExclusive(FLock); end;
end. |
PS: Eigentlich müsste man noch InitializeSRWLock aufrufen, aber die Funktion setzt den Pointer einfach nur auf nil. Der SRW-Lock verwendet nur den einen Pointer, um den Zustand zu speichern. Nil ist dabei der natürliche Ursprungswert wenn noch nichts gelockt ist.
Wer auf der sicheren Seite sein will, kann die Funktion gerne noch hinzufügen.