[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH] Thread-safe graphics manager
From: |
Maciek Gajewski |
Subject: |
[PATCH] Thread-safe graphics manager |
Date: |
Fri, 4 Jul 2008 23:39:04 +0200 |
User-agent: |
KMail/1.9.9 |
Hello
Attached is my implementation of locking in gh_manager. I sent it here for
review.
It's based on Michael Goffioul's patch from January (
http://www.nabble.com/Octave-backend-synchronization-td15038411.html ).
This implementation differs from Michael's in few ways:
- Mutex initialization is moved to gh_manager constructor. Previous version
wasn't thread safe - possiblerace could occur during first lock() invocation,
when two threads could start initializing mutex simultaneously.
- Mutex is explicitly defined as recursive, allowinf for nested locks/unlocks.
- Added simle lock_guard object which simplifies mutex usage.
- Locking is added in many more places:
* everywhere where object is obtained and it's properties changed,
* where multiple properties are being manipulated/read, to maintain
consistency,
* in higher-level methods, like 'xset' or 'get_property_from_handle' to make
them atomic.
It doesn't use boosts. Michael's implementation for Windows using critical
section is still there, and pthread-based for Unix is added.
This code is tested on Linux. It compiles cleanly and works fine. But this
still should be considered a draft. It needs longer, more throughout testing.
I'll port my entire backend to use it and test it for some time.
The performance of locking (at least on linux) is surprisingly good.
On my machine calling lock() 1000 times recursively takes 0.029 ms, then
unlocking 1000 times takes 0.04 ms
Machine spec: Linux-2.6.24-19 x86_64 working on single AMD Athlon(tm) 64
Processor 2800+ with 1800 MHz.
thread-safe-grpahics.patch
Description: Text Data
- [PATCH] Thread-safe graphics manager,
Maciek Gajewski <=