In MSDN there is a widely cited article about lockless programming on
x86 and Xbox: http://msdn.microsoft.com/en-us/library/ee418650(v=vs.85).aspx
In short: using boolean as a flag for thread termination is OK. Using
boolean as a guard for multi-threaded access to data isn't OK, as read
/ write re
15.12.2010, в 10:36, Stephan Aßmus написал(а):
> The only thing one needs to watch out for is to declare such a boolean
> volatile (which I believe this code does, if memory serves). Otherwise the
> thread which polls the condition may read from a cached location and miss the
> change. Worst t
On Dec 15, 2010, at 8:47 AM, Brady Eidson wrote:
>
> On Dec 15, 2010, at 4:28 AM, Steve Block wrote:
>
>> I have a question about whether WebCore code makes assumptions about
>> the atomicity of certain read/write operations.
>>
>> The particular instance I'm interested in is IconDatabase, whe
Thanks for the reply Brady.
> The boolean in question isn't both checked and set at the same time - it's
> not an acquired resource. One
> thread sets it, the other checks it.
I don't follow. If it's set from one thread and checked from another
thread without locks, how can you guarantee this (o
>>> The boolean in question isn't both checked and set at the same time - it's
>>> not an acquired resource. One
>>> thread sets it, the other checks it.
>> I don't follow. If it's set from one thread and checked from another
>> thread without locks, how can you guarantee this (other than with
>>
On Dec 15, 2010, at 11:11 AM, Steve Block wrote:
> Thanks for the reply Brady.
>
>> The boolean in question isn't both checked and set at the same time - it's
>> not an acquired resource. One
>> thread sets it, the other checks it.
> I don't follow. If it's set from one thread and checked from
Hi,
Am 15.12.2010 18:43, schrieb Brady Eidson:
On Dec 15, 2010, at 8:47 AM, Brady Eidson wrote:
On Dec 15, 2010, at 4:28 AM, Steve Block wrote:
I wouldn't be surprised if there were other examples of an unprotected thread
shared boolean in either WebCore or any platform's WebKit.
In hindsigh
On Dec 15, 2010, at 8:47 AM, Brady Eidson wrote:
>
> On Dec 15, 2010, at 4:28 AM, Steve Block wrote:
>
>> I have a question about whether WebCore code makes assumptions about
>> the atomicity of certain read/write operations.
>>
>> The particular instance I'm interested in is IconDatabase, whe
On Dec 15, 2010, at 4:28 AM, Steve Block wrote:
> I have a question about whether WebCore code makes assumptions about
> the atomicity of certain read/write operations.
>
> The particular instance I'm interested in is IconDatabase, where
> m_threadTerminationRequested is written to from the main
I have a question about whether WebCore code makes assumptions about
the atomicity of certain read/write operations.
The particular instance I'm interested in is IconDatabase, where
m_threadTerminationRequested is written to from the main thread (in
close() for example) and read from the DB thread
10 matches
Mail list logo