octave-maintainers
[Top][All Lists]
Advanced

[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.

Attachment: thread-safe-grpahics.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]