Tyd om in te sluit
Asinchrone funksies in Javascript is nie regtig parallel nie. Vanaf ES2017 het Javascript ondersteuning vir gelyktydige funksie-oproepe. Die verskil word deur Madhavan Nagarajan baie mooi saamgevat in die volgende verklaring (skakel kan in die addendum gevind word).
Gelyktydigheid gaan oor die hantering van baie dinge tegelyk. Parallelisme is om baie dinge tegelyk te doen.
Die implementering van Javascript se gelyktydigheid word verminder in sy funksionaliteit om 'n eenvoudige en baie robuuste API te gebruik. Async-funksies kan nie onderbreek word nie en het geen begrip van vlugtige eienskappe wanneer u toegang tot dieselfde veranderlike deur verskillende asynchrone oproepe het nie. Die gedetailleerde implementering van ES2017 se async-funksies is buite die omvang van hierdie artikel, maar die belangrikste punt wat ek wil deurvoer, is dat parallelisme tot nou toe nie in Javascript en op die web ingebou is nie, en dat daar dus geen spesiale hantering van parallelle mutasies van die dieselfde entiteit. Maar dit verander nou met die bekendstelling van die "Web Locks API".
Een vir almal en almal vir een
Noudat progressiewe webprogramme u ware multidraad-argitekture bied met die bekendstelling van WebWorkers en die ServiceWorker, het dinge verander. Ware parallelisme is moontlik in webprogramme, en daarom ontstaan die begeerte na meer gesofistikeerde instrumente om parallelle kode te hanteer.
'N Slot is 'n meganisme om toegang tot hulpbronne aan te vra en waarborg dat slegs een proses op enige tydstip regtig toegang het. Deur hulpbronne op hierdie manier te sluit, word 'n groot stel konflikgebiede vermy wat andersins kan ontstaan.
'N Hulpbron is slegs 'n naamruimte, geïdentifiseer deur 'n string. En u versoek om toegang tot die bron te verkry, is net so eenvoudig, aangesien u slegs die ID en 'n funksie-terugbel nodig het, waarskynlik asynchroon, om die "Web Lock API" te implementeer. As een async-funksie klaar is, word die slot vrygestel en kan ander versoeke weer toegang kry.
/*
* A simple demonstration of the Web Lock API.
* Note that this example has been taken from
* MDN's awesome documentation, linked in the
* addendum.
*/
async function foo(){
// A common async function that you already know.
const data = await getData();
// Request the lock.
// Note that we can simply await the locked call!
await navigator.locks.request('lock_resource_id', async lock => {
// The lock has been acquired.
// At this point, this call has exlusive access
// to the resource 'lock_resource_id'.
await updateDb(data);
// Now the lock will be released.
});
// The lock has been released.
// Continuse with plain async calls.
await updateUi();
}
As gevolg van die eksperimentele toestand van hierdie nuwe API, moet u dit as 'n opsionele funksie in u kode beskou, met 'n geldige terugval beskikbaar.
/**
* Due to the usage of web locks in core parts
* of your app, actually using the API this way
* might introduce more problems then it could solve.
*
* Therefore a thorough specification in your app
* has to be implementation before using this feature.
*/
async function update(){
if(navigator?.locks){
// Run logic with lock.
} else {
// Use fallback.
}
}
Om hierdie nuwe API beter te illustreer, kyk ons na 'n eenvoudige voorbeeld. Sê nou jy het 'n multi-threaded PWA met jou hoofproses en twee WebWorkers. U app gebruik ook 'n IndexDB, met persoonlike kode wat veranderinge van en na die databasis met die wolk sinkroniseer. Met behulp van die "Web Lock API" in hierdie scenario, kan elke proses toegang tot die gedefinieerde slot versoek om veranderinge aan die databasis te sinkroniseer, en sorg dat geen ander mutasies tydens hierdie oproep uitgevoer word nie.
Let daarop dat die "Web Lock API" nie soseer gaan oor die mutasie van 'n enkele veranderlike sonder newe-effekte in u webapp nie (alhoewel dit duidelik 'n gebruiksgeval kan wees), maar meer oor die hantering van funksie-oproepe in 'n parallelle argitektuur wat andersins sou lei tot negatiewe newe-effekte.
Baie meer om te leer
Hierdie artikel het slegs 'n inleiding gegee tot die nuwe "Web Locks API", wat tans in eksperimentele status is en hoofsaaklik deur Chromium-gebaseerde blaaiers ondersteun word. Die API bied meer opsies wat hier beskryf word, en dit is die moeite werd om dit te ondersoek.
