🚀 go-pugleaf

onegdaj ‟Michoo” rzecze:
> minięty czas pisze:
>> onegdaj ‟Michoo” rzecze:
>>> koszt całości jest niewielki, mimo, że lock zaburza trochę
>>> przetwarzanie strumieniowe (blokada magistrali)
>>     raczej  nie  ma  gwarancji, że jednemu wątkowi się powiedzie w
>>     pier-
>> wszym podejściu, chyba że w doborze instrukcji i ich ułożeniu
>> uwzględnić docelową architekturę, by wydawało się, że dzięki
>> jednoczesnemu przetwa- rzaniu kilku instrukcji przetworzy je w jednym
>> cyklu.
> Przeczytaj dokumentację intela, ok?
> 
> cmpxchg składa się z szeregu operacji mikrokodu oraz 2 dostępów do
> magistrali (wykonywanie tej instrukcji na rejestrach ma mało sensu).
> Faza 1: pobrania wartości z pod adresu i wykonanie porównania. Faza 2:
> zapisanie wyniku pod adres w pamięci LUB do rejestru.
> 
> Ponieważ w 2 fazie nie zawsze jest zapis do pamięci pomiędzy nimi
> magistrala jest zwalniana - przy dużym, równoległym ruchu na procesorze
> 2 rdzeniowym wszystko się sypie w ułamku sekundy. Dodanie prefiksu lock
> powoduje zablokowanie dostępu do magistrali i danych w pamięci cache
> (cache coherency) na czas całej instrukcji. Czyli po prostu zapewnia
> ATOMOWE WYKONANIE instrukcji.
> 
> Skoro atomowe, to ten kto pierwszy ją zaczął ten zatrzymał pipeline
> wszystkich innych na czas 2 dostępów do pamięci i wymusił u nich
> odświeżenie cache - jego nikt nie zatrzyma.
> 
>>     to  co  powyżej  to  jest  właśnie  blokada  dostępu (czyli  tzw.
>> ‘lock’), ale  przeniesiona  na  poziom instrukcji procesora
>> architektury ‘cisc’, co nie oznacza, że automatycznie zawsze i w każdym
>> przypadku ta- ka  instrukcja  jest  wykonywana  bez dodatkowych
>> kosztów, niewidocznych dla  programu.
> Napisałem, że koszta są - niewielkie.
> 
>> więc wydaje się, że odpowiedniejszą nazwą dla tego typu algorytmów
>> byłaby ‘mutex—free’, czyli pozbycie się blokowania uniwersal- nego  na 
>> rzecz  blokowania  wewnątrzprocesorowego.   jakby  zmierzanie do 
>> rozwiązań  typu ‘clean  box’, ale  w rzeczywistości  to  jest zwykłe
>> ‘black box’… ;-)
> Jakbyś się dokształcił w kwestii tego jak działa arbitraż na magistrali,
> jak działa cache coherency protocol, jak wygląda zazwyczaj cykl
> rozkazowy, jak działa pipeline to byś doszedł do wniosku, że: a)
> wszystkie instrukcje są blokujące, bo w ich obrębie jest blokowana np.
> magistrala
> lub
> b) dodanie prefiksu lock sprawia, że jeden opcode jest tłumaczony na
> jedną instrukcję, a nie kilka.
> 
> Potem moglibyśmy kontynuować dyskusję na temat zastosowań?
> 
>> i jak by wyglądał taki algorytm na procesor ‘risc’…?
> Poczytaj specyfikację choćby arm7 (LDM). Tam jest zazwyczaj łatwiej, bo
> nie ma systemów wielordzeniowych i wystarcza zablokowanie przerwań do
> czasu ukończenia instrukcji. Jeżeli jest wiele procesorów/rdzeni/(dma)
> to już wchodzi jakiś arbitraż na magistrali i trzeba blokować równoległy
> do niej dostęp.
    jesteś  zwykłym trolem, który przepisuje przepisane wiadomości i do-
łącza  tylko tekst „czytaj to!” (“README.TXT”).   byłeś już w plonkowni-
cy, ale chwilowo to zignorowałem, bo odpowiedziałeś na mój tekst techni-
cznie —nigdy więcej. :-)
    nie  rozumiesz  całości podanego przez siebie przykładu, a pouczanie
innych  do  czytania tego co ty i nie rozumienia w taki sam sposób sobie
daruj… :->   he‐he‐he…
    PLONK2
-- 
 qo   |)      CPL<=dataDPL CPL==/>=codeDPL:conform'/nc';max=CPL! AV0ID bHp
    _x/ ,     CPL<=TSS,gateDPL CPL>=/==dest_DPL:/(jmp&nc') ,RPL!- #GP -o0o
    |    ng  __ -- __ -- __ -- __ -- __ -- __ -- __ -- __ -x86-, EV3RY o0o
,__ -- __ -- Current/Requested/DescriptorPrivilegeLevel C/R/DPL , d4y m:#=