On Tue, Jun 28, 2011 at 10:33 AM, Hans-Peter Diettrich <[email protected]> wrote:
> Big Q: *which* resource? > > A critical section (process-local MUTEX) is not related to a specific > (memory) resource, except itself, consequently it can not protect any > *other* resource. It also does not block any other thread, not waiting for > entering the critical section, so that all resources are accessible by all > threads, except the critical section (or mutex...) itself. 100% correct. That's what I've been saying. I think some think that its some magical solution that protects everything under the sun. >> Thus a concurrent access might erroneously offer a not updated state to >> the other CPU. > > Right. All threads keep running, except those waiting for a critical section > in use, so that concurrent access can occur in all threads. Simple semantics. >> Regarding Data Cache, AFAIK, the hardware prevents this. If one CPU writes >> a value, an "invalidate" signal for the addresses in that cache line is sent >> to all caches, and so all other CPUs will reread the data from the main >> memory, which in turn will force a preliminary write from cache to main >> memory for the cache line of the first CPU. > > An invalidated cache line does not cause a reload from RAM. A reload only > occurs when the next read will result in an cache miss. OK folks. Can we please focus around this comment ??? This is what makes a piece of memory volatile with respect to threading/cores. CAS / Interlocked mechanisms are the solution to this issue. But are there others? >> Thus "Locked" instructions (that force this mechanism, guaranteeing proper >> read-modify-write access even if multiple instructions access the same data >> are issued at the same time <overlapping execution> ) only are necessary >> outside a critical section protecting the data in question. > > That's wrong, since a critical section does not protect any range of memory > addresses. Ok another focus here. Lets make the distinction between Thread Locks and Interlocked/Compare and Swaps here. Anyone else got anything to add here? > A locking instruction most probably will invalidate the address in all > caches, before reading from or writing to the specified address. Since the > RAM is locked during the instruction, all other cores or processors have to > wait until the end of the instruction cycle, before they can access the same > address. This is good info. This is exactly what I observed on my AMD 1075Ts >> My conclusion is, that the said problem with linked lists results from the >> pointers not being defined as "volatile". > No. In a bidirectionally linked list up to 4 pointers have to be updated > together, whenever an element is inserted or removed. This leaves much room > for race conditions, that cannot be cured by protecting every single > pointer. Instead the entire chain must be protected, by a MUTEX or other > synchronization means. And then it's only a *convention*, which object or > memory block shall be protected by a MUTEX, no memory barrier prevents > access without obtaining the MUTEX first. Kind of a memory barrier can be > established by putting the list object (head) into a TThreadList, *provided > that* no code will retain references to list elements after releasing the > list object. I had a similar issue once. And it was solved with bringing the list under my manager/worker system so that there was only one thread accessing the linkedlist, and I used InterlockedExchange for First,Last,Next,Previous. >> And I really don't know how this could be cured in Pascal other than doing >> ASM. (I was not aware of this problem and I feel it should be discussed in >> the FPC mailing list.) > It's not a matter of the language, when a thread does *not* aquire a lock > before accessing the related resource. It's simply a design flaw, when some > piece of code does not obey the established rules. I don't see how this is an issue of obedience. It's more of a phenomenon. -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
