[Kolab-devel] pykolab/format

[Christian Mollekopf]

On Friday 24 February 2012 12.12:31 Jeroen van Meeuwen wrote:
> On 2012-02-24 10:58, Jeroen van Meeuwen (Kolab Systems) wrote:
> > On 2012-02-24 8:55, Christian Mollekopf wrote:
> >> pykolab/format/tests/test-thread_safety.py |   68
> >> +++++++++--------------------
> >> 
> >>  1 file changed, 22 insertions(+), 46 deletions(-)
> >> 
> >> New commits:
> >> commit cb63be089fce18dd9899526455022dad10f8e2ac
> >> Author: Christian Mollekopf <mollekopf at kolabsys.com>
> >> Date:   Fri Feb 24 09:54:15 2012 +0100
> >> 
> >>     Actually call the function from different threads instead of the
> >> 
> >> main thread.
> > 
> > Hi Christian,
> > 
> > I'm reverting this change, renaming the resulting test (the
> > original),
> > and applying your version of the test as the test for thread safety.
> 
> Let me rephrase, because maybe I'm not going to do any of that... Not
> Sure Yet(TM)
> 
> If I understand correctly, getSerializedUID() is called from within the
> child thread, even though the reason for it to be called is coming from
> the main thread's <thread>.uid() call.  It seems though the most
> upper-level thread causing the function to be called is the thread under
> which it runs - and thus getSerializedUID() returns that thread local
> value?
> 

Hey Jeroen,

In test-thread_safety.py  there shouldn't be any call to getSerializedUID() 
from the main thread from what I see. We start two child threads, which 
execute what they have in their run() method, which seems to be the start 
point of every thread in python. 
(http://docs.python.org/library/threading.html#thread-objects)
The call to Thread.start() will trigger the invocation of run() in the new 
thread at some point. From this point on you have no control what happens in 
the subthread anymore until you use some synchronization. In our case we 
synchronize the threads again by calling join(), which waits until the threads 
are finished and allows us to retrieve our results.

In your test you're using the "target" callable parameter which should give 
you the same result, if you can really pass a function as callable object 
(seems to work).

> Now, I've attached a parallel_threads test, which succeeds, but does a
> full mesh of comparisons. Note I do not have to time.sleep() - but I
> added some tests that sleep anyway.
> 
> Could you please examine the output (including what I am assuming are
> the thread identifiers spit out to stdout/stderr by libkolabxml), and
> confirm/deny whether or not these tests are appropriate / do what we
> expect them to do?
> 

Yes, the debug output (which you have to activate in utils.cpp, ThreadLocal 
class), are the thread-identifiers.

It seems to work sometimes, but sometimes also not. I suspect that threads are 
being reused because you run the threads sequentially instead of in parallel 
(you sleep first).

So the test doesn't really test anything because that would even work in a 
single thread. That's also why I used a for loop in the run() method and start 
both threads immediately. The sleep between the runs in run() ensures that it 
is highly unlikely that one thread can finish before the other managed to 
start. This way I can be fairly sure that both threads actually access  the 
thread local storage in parallel (to be perfectly sure we'd have to use 
locking between the two threads).

It's also not quite clear what you want to test with this test, since the 
other one already proves that the thread-local storage work, the basic test 
you're doing (the uid hasn't changed after the sleep) seems to be the same, 
though the analysis of the error state is more in depth (though useless 
because it works =).

Hope that clears things up.

Cheers,
Christian

> Kind regards,
> 
> Jeroen van Meeuwen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20120301/38b623ac/attachment.sig>