[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    [kopete-devel] Re: kopetexsl.cpp
From:       Richard Smith <kde () metafoo ! co ! uk>
Date:       2005-02-26 14:24:15
Message-ID: 200502261424.15350.kde () metafoo ! co ! uk
[Download RAW message or body]

On Saturday 26 February 2005 14:03, Martijn Klingens wrote:
> On Saturday 26 February 2005 13:49, Richard Smith wrote:
> > But now I'm not sure I follow your other argument for why the mutex is
> > necessary in this specific case (though I wouldn't be at all surprised if
> > it is). AFAICS the write to m_resultString must have fully completed
> > before the user event is sent to the GUI thread, which seems to imply
> > that subsequently reading it in the GUI thread should be safe. There
> > seems to be no chance of either thread reading partially-written data. As
> > an intellectual exercise, what, if anything, might go wrong if the mutex
> > were removed?
>
> I don't know the code, so the below text is the generic description and not
> specific to KopeteXSL.
>
> Basically there are three possible situations in threaded code:
>
> 1. The logical flow of operations is such that it is impossible that thread
> 1 and thread 2 access data at the same time. This can happen if one thread
> is sleeping or blocking. It's at the same time the most simple and most
> dangerous situation. Simple, because no special precautions need to be
> taken in the code. Dangerous, because if you incorrectly assume this to be
> the case while in fact two threads *do* run in parallel on the same data
> you're in deep problems. See #2 and #3 below for what happens :)
[...]
> As far as I understand your question, you're writing to a string, i.e. #3.
> However, you're also referring to a user event. This might imply #1.

It's #1. The string is written to, only ever once, by one thread. Then, that 
thread posts an event to the GUI thread. Then, the GUI thread reads from the 
same string. So it seems the mutex is safe to remove for the time being 
(though I'd feel more comfortable if we didn't remove it).
-- 
Thanks,
Richard
_______________________________________________
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel
[prev in list] [next in list] [prev in thread] [next in thread]