Re: [PATCH] Thread-safe graphics manager

[Michael Goffioul]

On Fri, Jul 4, 2008 at 11:39 PM, Maciek Gajewski
<address@hidden> wrote:
> 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.

Do you really need to add locking at all these places? Isn't it enough
to add locking at the entry-point the user has access to, meaning the
DEFUN_DLD functions? In any case, octave will access the graphics
system through one of these function, right?

Note: I like the lock_guard system, it's easier to use from the user
point of view.

Michael.