GC, the simple solution
Sean Kelly
sean at f4.ca
Sat Jun 10 11:39:35 PDT 2006
Bruno Medeiros wrote:
> Sean Kelly wrote:
>> Bruno Medeiros wrote:
>>> Walter Bright wrote:
>>>>> Only if the reference is stored,
>>>>> the ref counter has to be incremented. This is only possible if
>>>>> this is
>>>>> done by the compiler. No smart pointer can do this :)
>>>>>
>>>>>> 3) in a multithreaded app, the incs and decs must be synchronized
>>>>>
>>>>> Isn't a atomic inc/dec enough?
>>>>
>>>> That requires synchronizing.
>>>>
>>>
>>> Are you sure? It says in
>>> http://www.iecc.com/gclist/GC-algorithms.html#Reference%20counting that:
>>> "In a multi-threaded system, if threads are preemptively scheduled,
>>> reference counting requires additional care to ensure that the
>>> updates to reference counts are atomic. This is straightforward using
>>> hardware primitives such as fetch-and-add, compare-and-swap, or
>>> load-linked/store-conditional, but it is definitely necessary to pay
>>> attention to this detail." ?
>>
>> These are synchronizing operations.
>
> By "That requires synchronizing." I thought Walter meant stuff with
> mutexes, etc. (i.e., non-trivial stuff), because, can't those hardware
> synchronizing operations be called "atomic inc/dec" ?
For the most part. There are really two issues here. First, the
operation must be atomic with respect to other threads. The x86
actually guarantees this for all load/store operations on aligned data
<= the bus size. Second, the operations must be observed in the proper
order by other threads--ie. the compiler and all involved CPUs (reader
and writer) are not allowed to reorder the operations or do any other
fancy tricks that may result in a load/store order that isn't the same
as program order. For the compiler, this is where volatile comes in,
and at the hardware level, a synchronizing operation may be required
depending on the situation and on the hardware involved. Again, with
x86 you can get away without a LOCK a lot of the time, but not always.
So you really must assume that any competing operation has a worst case
cost of... well, a lot.
Sean
More information about the Digitalmars-d
mailing list