Inlägg

Men både List<T>(ICollection)
och List.RemoveAt(int index)

Gör Memcopy under ytan, så visst den måste flytta alla bytes i minnet, men kan det verkligen ta mer tid än O(N) för borttagning av ett element?

edit: Jag gör ju iof inte RomveAt utan Remove vilket i värsta fall ger O(N) men i snitt O(N/2)

Får benchmarka lite men jag undrar om det blir så mycket snabbare än en list då jag måste ta bort subscriptions.
Dock tror jag inte jag vill ha beroenden till FSharp.Core.dll då detta är ett lib som man kan installera via Nuget, tror folk lackar lite om mitt paket drar in F#

Men borde finns Imutable linked lists på nätet för C#, eller skriva en själv, inte så svårt då jag bara behöver vissa metoder.

Det lutar iallafall åt Locked write unlocked read eller vad säger ni?

edit: Mitt lilla enhetstest klarade att subba / unsubba samtidigt som 1 miljon events triggade på 11 sekunder och då med min list implementation så kanske inte behöver oroa mig för Listans prestanda.
Dock så kör det testet unsub lika ofta som sub mao inte så många subs samtidigt. För att verkligen testa Listan impakt på prestandna borde jag köra unsub mycket mer sällan i testet så det ligger ett par tusen sub's i listan

Men jag måste ju ta bort gamla subscriptions annars får du en fet lista till slut som tar O(N) där vädligt liten del av N faktiskt är aktiva subscritions att läsa igenom för att inte tala om minnesluckan det skapar, men du kanske menar nått annat?

lustigt, tänkte precis på länkade listor, ska testa #2 med det. Tack för input

edit: dock kan den inte vara omuterbar då jag måste kunna ta bort subscriptions

@Rupertoo
Eftersom det är ett lib så kan jag inte veta exakt hur folk kommer använda det. Men normalfallet måste ju vara att det är oftare events som publiceras än det är klienter som ansluter sig till att lyssna?

Det är två * två collections alltså fyra, de ser ut såhär

        private readonly IDictionary<Guid, List<Subscription>> subscriptions;
        private readonly IDictionary<string, List<Type>> userSubscriptions;

Den första indexerar en Dictionary på EventType (GUID då de ska funka även med Type<T, Tn> där T-Tn är godtycklig) värdet i listan är alla subscriptions som lyssnar på det eventet

Den andra indexerar på SignalR ConnectionId och listan innehåller alla events som den klienten lyssnar på

userSubscriptions används bara vid Sub / unsub medans subscriptions används från båda.

Jag har redan testat Teknocide lösning 1) och 2)
Ettan skalar ju inte alls i Multitrådat, 2an är jag lite orolig för då den kopierar enumeratorn till en ny dic. Har du många events och många som ansluter kan detta införa problem, däremot är den ju snabb vid Read då du inte behöver låsa.
3an är intressant, den är ju rätt lik tvåan men du slipper kopiering, men ska den helt ta bort trådproblem måste ju även Handle metoden köras på samma tråd och då är vi ju tillbaka vid att det inte skalar alls?

Jag har ett litet Pub/sub Lib för SignalR, de viktigaste funktionerna finns där men innan jag pushar det till 1.0 status måste jag se till att den klarar av samtidiga operationer då flera användare kan subscriba samtidigt eller pub's itererar över sub's samtidigt som en annan tråd anropar sub.

Koden finns här
https://github.com/AndersMalmgren/SignalR.EventAggregatorProx...

Jag har valt att projicera subscriptions på två aggregatrötter, dels på event typ och dels på connectionId.

Det är 3 metoder som skriver / läser till dessa

• Subscribe

• Unsubscribe

• UnsubscribeConnection

Medans en som bara läser

• Handle

Jag skrev ett litet test för att testa att koden är trådsäker
https://github.com/AndersMalmgren/SignalR.EventAggregatorProx...

Jag har även uppdaterat den koden med lite benchmark kod så jag kan testa prestandan, men den koden har degenererat under tiden jag testat olika metoder så måste skriva om den innan jag kan commita den.

Den mest säkra metoden är att lägga lås runt alla fyra metoder, men då skalar ju koden exakt noll med fler trådar. Jag har även testat att lägga lås runt de tre subscribe / unsubscribe metoderna och sedan ha en ToList när jag itererar över sub'sen i (En kopia som då itereras över). Detta fungerar oftast men var tusende eller så iteration crashar då även ToList metoden inte är trådsäker. Dock ger detta ganska bra prestanda och skalar bra över flera trådar. Men det är ju inte hållbart att koden crashar då detta innebär att vissa klienter inte kommer få pub'en. Jag testade även att låsa kopieringen och låta resten av Handle metoden vara olåst. Detta gav knappt märkbar prestandaökning mot att låsa hela metoden.

Stämmer inte på mig iaf, däremot håller jag koll på andra duktiga Scouthelis på fiendelaget så jag vet vad jag möter i luften

Om det är hobby eller ej spelar ingen roll om du låter folk regga dig på din sida. Man bara får inte lagra lösenord i klartext/krypterat. Du måste använda ett hash som är omöjligt (inget är omöjligt men så svårt som möjligt) att reversera.

edit: ah, det är Windows auth?

Du ska inte kryptera lösenorden, det är big no, no. Om någon hacker kommer åt din DB är det bara att läsa av lösenorden och användarnamnen. Vad du ska göra är att hasha lösenorden + salta dem

http://stackoverflow.com/questions/5186070/how-to-start-git-d...

Jag håller helt med dig, vill bara upplysa att hastigheten man pollar kan spela roll. Tex sensor fusion (IMU), ju fler samplar du hanterar per sekund desto mindre drift och högre träffsäkerhet får du. Men absolut ett specialfall och i detta fall duger nog non blocking IO på main tråden.

edit: Concurrent kollektionerna i .NET är tänkta för fleranvändarsystem, de är inte designade för parallellisering på det sättet.

Kolla in Twitter bootstrap, mycket bra när man ska skriva responsiva sidor

Finns massor av olika Tile bases engines (2D) som wrappar OpenGL, detta är att föredra för hackfria spel

Googla lite snabbt, här har du en
http://www.andengine.org/

Antingen lägger du den i samma tråd som videoavkodningen eller så kör du en Thread.Sleep(1) i din pollningstråd. Du får tänka på att klockan in win32 går på 64hz så du kommer hamna på ungefär 16 ms sleep. Är det för segt så kan du använda Thread.Yield istället, detta betyder att din tråd går så snabbt den kan men lämnar CPU-tid till andra trådar och processer

Non blocking IO är bra, men ibland kan maintråden vara för seg för input, tex om man vill göra beräkningar som olika filter eller interpolation. Men i detta fall så lär det bara vara att köra på!

http://msdn.microsoft.com/en-us/library/ms751565.aspx

Ska jag lägga upp mitt lönebeked? Tycker vi kan släppa detta? 2013 deklarationen kommer dessutom vara helt missvisande då jag tjänade ca 25-27k Jan / feb då det är taket för föräldrapenningen.

Hur som helst, min poäng är att du behöver verkligen inte byta jobb för att göra en stor löneökning. Däremot hjälper det ju att hinta sin närmaste chef om att andra bolag rycker i en

Det är exakt noll skillnad på en Bakgrundstråd och en Background worker. Dock ska man inte använda trådklassen direkt så en Backgroiundworker eller ThreadPool är bättre.

edit: En Bakgrundstråd är en helt vanlig tråd konfad att dö om huvudprocessen dör

Jag har aldrig sagt att jag haft 55 i snitt de senaste 6 åren? (Det jag sade var att det är snittet för 2013)

Du kunde ha tjänat samma summor även på samma bolag, det handlar om att lära sig förhandla. På mitt bolag är det jättestor variation på lönen, en del av det är såklart variation på kompetens, men ännu större anledning är stor variation på förhandlingskompetens.

I snitt ja. På samma sätt ger du en orealistisk bild åt andra hållet. Att byta jobb vartannat år kan ge en bild att du är oseriös och olojal.

Men till TS kan jag säga att det är inte omöjligt att tjäna 50 plus men det räcker inte med en nine to five insats