Re: [platform-swt-dev] Acquiring a global lock in SWT GTK implementation

[Silenio Quarti <Silenio_Quarti@xxxxxxxxxx>]

The reason SWT locks all natives in OS
is because Xlib is not thread safe.  Search bugzilla or google for
"Xlib: unexpected async reply" and you will find a lot of info
about this problem.   Even if you are not sharing the image/gc in
multiple threads, deep in XLib there is global data that needs to be protected.
  GTK and Xlib offer locking APIs but they are not re-entrant which
force SWT to implement its own locking mechanism using what was available
in Java at the time.    It should be use enough to try other
locking strategies (MCS) by just replacing org.eclipse.swt.internal.Lock.

Now, 94% seems awfully high and deserves
investigation. I would suggest opening a bug report with steps to reproduce
it.

Silenio



From:      
 laksono <laksono@xxxxxxxxx>
To:      
 platform-swt-dev@xxxxxxxxxxx,

Date:      
 09/19/2013 03:01 PM
Subject:    
   [platform-swt-dev]
Acquiring a global lock in SWT GTK implementation
Sent by:    
   platform-swt-dev-bounces@xxxxxxxxxxx

---

Dear all,

Is there any reasons why in org.eclipse.swt.internal.gtk.OS
class, we need to use a global lock to access any _g* functions as shown
below:

public static final int gdk_drawable_get_depth(long /*int*/ drawable)
{
    lock.lock();
    try {
        return _gdk_drawable_get_depth(drawable);
    } finally {
        lock.unlock();
    }
}

I ask this question because locks can cause performance
impact badly, especially if we use multiple threads to draw on its private
image (not shared image). We have experimented using 32 java threads (on
top of 32 hardware threads) to draw on 7680×4320 (33 million pixels) on
Linux/GTK platform, and 94% of the total execution time of the application
is spent on lock.

Thus, do we need to wrap gdk native routines with a global
lock ? Is it possible to avoid lock if we just want to draw on "private"
image or private GC ? The reason we use multiple threads is we want to
draw in parallel, but unfortunately due to lock, the drawing is serialized.


On a separate issue: is org.eclipse.swt.internal.Lock
implementation scalable ? Some lock contention free algorithms such as
MCS lock is perhaps more suitable ?

Regards,

Laksono Adhianto_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev