Search Results

Search found 8166 results on 327 pages for 'thread syncronization'.

Page 58/327 | < Previous Page | 54 55 56 57 58 59 60 61 62 63 64 65  | Next Page >

  • Win7 Bluescreen: IRQ_NOT_LESS_OR_EQUAL | athrxusb.sys

    - by wretrOvian
    Hi I'd left my system on last night, and found the bluescreen in the morning. This has been happening occasionally, over the past few days. Details: ================================================== Dump File : 022710-18236-01.dmp Crash Time : 2/27/2010 8:46:44 AM Bug Check String : DRIVER_IRQL_NOT_LESS_OR_EQUAL Bug Check Code : 0x000000d1 Parameter 1 : 00000000`00001001 Parameter 2 : 00000000`00000002 Parameter 3 : 00000000`00000000 Parameter 4 : fffff880`06b5c0e1 Caused By Driver : athrxusb.sys Caused By Address : athrxusb.sys+760e1 File Description : Product Name : Company : File Version : Processor : x64 Computer Name : Full Path : C:\Windows\minidump\022710-18236-01.dmp Processors Count : 2 Major Version : 15 Minor Version : 7600 ================================================== HiJackThis ("[...]" indicates removed text; full log posted to pastebin): Logfile of Trend Micro HijackThis v2.0.2 Scan saved at 8:49:15 AM, on 2/27/2010 Platform: Unknown Windows (WinNT 6.01.3504) MSIE: Internet Explorer v8.00 (8.00.7600.16385) Boot mode: Normal Running processes: C:\Windows\DAODx.exe C:\Program Files (x86)\ASUS\EPU\EPU.exe C:\Program Files\ASUS\TurboV\TurboV.exe C:\Program Files (x86)\PowerISO\PWRISOVM.EXE C:\Program Files (x86)\OpenOffice.org 3\program\soffice.exe C:\Program Files (x86)\OpenOffice.org 3\program\soffice.bin D:\Downloads\HijackThis.exe C:\Program Files (x86)\uTorrent\uTorrent.exe R1 - HKCU\Software\Microsoft\Internet Explorer\[...] [...] O2 - BHO: Java(tm) Plug-In 2 SSV Helper - {DBC80044-A445-435b-BC74-9C25C1C588A9} - C:\Program Files (x86)\Java\jre6\bin\jp2ssv.dll O4 - HKLM\..\Run: [HDAudDeck] C:\Program Files (x86)\VIA\VIAudioi\VDeck\VDeck.exe -r O4 - HKLM\..\Run: [StartCCC] "C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static\CLIStart.exe" MSRun O4 - HKLM\..\Run: [TurboV] "C:\Program Files\ASUS\TurboV\TurboV.exe" O4 - HKLM\..\Run: [PWRISOVM.EXE] C:\Program Files (x86)\PowerISO\PWRISOVM.EXE O4 - HKLM\..\Run: [googletalk] C:\Program Files (x86)\Google\Google Talk\googletalk.exe /autostart O4 - HKLM\..\Run: [AdobeCS4ServiceManager] "C:\Program Files (x86)\Common Files\Adobe\CS4ServiceManager\CS4ServiceManager.exe" -launchedbylogin O4 - HKCU\..\Run: [uTorrent] "C:\Program Files (x86)\uTorrent\uTorrent.exe" O4 - HKUS\S-1-5-19\..\Run: [Sidebar] %ProgramFiles%\Windows Sidebar\Sidebar.exe /autoRun (User 'LOCAL SERVICE') O4 - HKUS\S-1-5-19\..\RunOnce: [mctadmin] C:\Windows\System32\mctadmin.exe (User 'LOCAL SERVICE') O4 - HKUS\S-1-5-20\..\Run: [Sidebar] %ProgramFiles%\Windows Sidebar\Sidebar.exe /autoRun (User 'NETWORK SERVICE') O4 - HKUS\S-1-5-20\..\RunOnce: [mctadmin] C:\Windows\System32\mctadmin.exe (User 'NETWORK SERVICE') O4 - Startup: OpenOffice.org 3.1.lnk = C:\Program Files (x86)\OpenOffice.org 3\program\quickstart.exe O13 - Gopher Prefix: O23 - Service: @%SystemRoot%\system32\Alg.exe,-112 (ALG) - Unknown owner - C:\Windows\System32\alg.exe (file missing) O23 - Service: AMD External Events Utility - Unknown owner - C:\Windows\system32\atiesrxx.exe (file missing) O23 - Service: ASUS System Control Service (AsSysCtrlService) - Unknown owner - C:\Program Files (x86)\ASUS\AsSysCtrlService\1.00.02\AsSysCtrlService.exe O23 - Service: DeviceVM Meta Data Export Service (DvmMDES) - DeviceVM - C:\ASUS.SYS\config\DVMExportService.exe O23 - Service: @%SystemRoot%\system32\efssvc.dll,-100 (EFS) - Unknown owner - C:\Windows\System32\lsass.exe (file missing) O23 - Service: ESET HTTP Server (EhttpSrv) - ESET - C:\Program Files\ESET\ESET NOD32 Antivirus\EHttpSrv.exe O23 - Service: ESET Service (ekrn) - ESET - C:\Program Files\ESET\ESET NOD32 Antivirus\x86\ekrn.exe O23 - Service: @%systemroot%\system32\fxsresm.dll,-118 (Fax) - Unknown owner - C:\Windows\system32\fxssvc.exe (file missing) O23 - Service: FLEXnet Licensing Service - Acresso Software Inc. - C:\Program Files (x86)\Common Files\Macrovision Shared\FLEXnet Publisher\FNPLicensingService.exe O23 - Service: FLEXnet Licensing Service 64 - Acresso Software Inc. - C:\Program Files\Common Files\Macrovision Shared\FLEXnet Publisher\FNPLicensingService64.exe O23 - Service: InstallDriver Table Manager (IDriverT) - Macrovision Corporation - C:\Program Files (x86)\Common Files\InstallShield\Driver\11\Intel 32\IDriverT.exe O23 - Service: @keyiso.dll,-100 (KeyIso) - Unknown owner - C:\Windows\system32\lsass.exe (file missing) O23 - Service: @comres.dll,-2797 (MSDTC) - Unknown owner - C:\Windows\System32\msdtc.exe (file missing) O23 - Service: @%SystemRoot%\System32\netlogon.dll,-102 (Netlogon) - Unknown owner - C:\Windows\system32\lsass.exe (file missing) O23 - Service: @%systemroot%\system32\psbase.dll,-300 (ProtectedStorage) - Unknown owner - C:\Windows\system32\lsass.exe (file missing) O23 - Service: Protexis Licensing V2 (PSI_SVC_2) - Protexis Inc. - c:\Program Files (x86)\Common Files\Protexis\License Service\PsiService_2.exe O23 - Service: @%systemroot%\system32\Locator.exe,-2 (RpcLocator) - Unknown owner - C:\Windows\system32\locator.exe (file missing) O23 - Service: @%SystemRoot%\system32\samsrv.dll,-1 (SamSs) - Unknown owner - C:\Windows\system32\lsass.exe (file missing) O23 - Service: @%SystemRoot%\system32\snmptrap.exe,-3 (SNMPTRAP) - Unknown owner - C:\Windows\System32\snmptrap.exe (file missing) O23 - Service: @%systemroot%\system32\spoolsv.exe,-1 (Spooler) - Unknown owner - C:\Windows\System32\spoolsv.exe (file missing) O23 - Service: @%SystemRoot%\system32\sppsvc.exe,-101 (sppsvc) - Unknown owner - C:\Windows\system32\sppsvc.exe (file missing) O23 - Service: Steam Client Service - Valve Corporation - C:\Program Files (x86)\Common Files\Steam\SteamService.exe O23 - Service: @%SystemRoot%\system32\ui0detect.exe,-101 (UI0Detect) - Unknown owner - C:\Windows\system32\UI0Detect.exe (file missing) O23 - Service: @%SystemRoot%\system32\vaultsvc.dll,-1003 (VaultSvc) - Unknown owner - C:\Windows\system32\lsass.exe (file missing) O23 - Service: @%SystemRoot%\system32\vds.exe,-100 (vds) - Unknown owner - C:\Windows\System32\vds.exe (file missing) O23 - Service: @%systemroot%\system32\vssvc.exe,-102 (VSS) - Unknown owner - C:\Windows\system32\vssvc.exe (file missing) O23 - Service: @%systemroot%\system32\wbengine.exe,-104 (wbengine) - Unknown owner - C:\Windows\system32\wbengine.exe (file missing) O23 - Service: @%Systemroot%\system32\wbem\wmiapsrv.exe,-110 (wmiApSrv) - Unknown owner - C:\Windows\system32\wbem\WmiApSrv.exe (file missing) O23 - Service: @%PROGRAMFILES%\Windows Media Player\wmpnetwk.exe,-101 (WMPNetworkSvc) - Unknown owner - C:\Program Files (x86)\Windows Media Player\wmpnetwk.exe (file missing) -- End of file - 6800 bytes CPU-Z ("[...]" indicates removed text; see full log posted to pastebin): CPU-Z TXT Report ------------------------------------------------------------------------- Binaries ------------------------------------------------------------------------- CPU-Z version 1.53.1 Processors ------------------------------------------------------------------------- Number of processors 1 Number of threads 2 APICs ------------------------------------------------------------------------- Processor 0 -- Core 0 -- Thread 0 0 -- Core 1 -- Thread 0 1 Processors Information ------------------------------------------------------------------------- Processor 1 ID = 0 Number of cores 2 (max 2) Number of threads 2 (max 2) Name AMD Phenom II X2 550 Codename Callisto Specification AMD Phenom(tm) II X2 550 Processor Package Socket AM3 (938) CPUID F.4.2 Extended CPUID 10.4 Brand ID 29 Core Stepping RB-C2 Technology 45 nm Core Speed 3110.7 MHz Multiplier x FSB 15.5 x 200.7 MHz HT Link speed 2006.9 MHz Instructions sets MMX (+), 3DNow! (+), SSE, SSE2, SSE3, SSE4A, x86-64, AMD-V L1 Data cache 2 x 64 KBytes, 2-way set associative, 64-byte line size L1 Instruction cache 2 x 64 KBytes, 2-way set associative, 64-byte line size L2 cache 2 x 512 KBytes, 16-way set associative, 64-byte line size L3 cache 6 MBytes, 48-way set associative, 64-byte line size FID/VID Control yes Min FID 4.0x P-State FID 0xF - VID 0x10 P-State FID 0x8 - VID 0x18 P-State FID 0x3 - VID 0x20 P-State FID 0x100 - VID 0x2C Package Type 0x1 Model 50 String 1 0x7 String 2 0x6 Page 0x0 TDP Limit 79 Watts TDC Limit 66 Amps Attached device PCI device at bus 0, device 24, function 0 Attached device PCI device at bus 0, device 24, function 1 Attached device PCI device at bus 0, device 24, function 2 Attached device PCI device at bus 0, device 24, function 3 Attached device PCI device at bus 0, device 24, function 4 Thread dumps ------------------------------------------------------------------------- CPU Thread 0 APIC ID 0 Topology Processor ID 0, Core ID 0, Thread ID 0 Type 0200400Ah Max CPUID level 00000005h Max CPUID ext. level 8000001Bh Cache descriptor Level 1, I, 64 KB, 1 thread(s) Cache descriptor Level 1, D, 64 KB, 1 thread(s) Cache descriptor Level 2, U, 512 KB, 1 thread(s) Cache descriptor Level 3, U, 6 MB, 2 thread(s) CPUID 0x00000000 0x00000005 0x68747541 0x444D4163 0x69746E65 0x00000001 0x00100F42 0x00020800 0x00802009 0x178BFBFF 0x00000002 0x00000000 0x00000000 0x00000000 0x00000000 0x00000003 0x00000000 0x00000000 0x00000000 0x00000000 0x00000004 0x00000000 0x00000000 0x00000000 0x00000000 0x00000005 0x00000040 0x00000040 0x00000003 0x00000000 [...] CPU Thread 1 APIC ID 1 Topology Processor ID 0, Core ID 1, Thread ID 0 Type 0200400Ah Max CPUID level 00000005h Max CPUID ext. level 8000001Bh Cache descriptor Level 1, I, 64 KB, 1 thread(s) Cache descriptor Level 1, D, 64 KB, 1 thread(s) Cache descriptor Level 2, U, 512 KB, 1 thread(s) Cache descriptor Level 3, U, 6 MB, 2 thread(s) CPUID 0x00000000 0x00000005 0x68747541 0x444D4163 0x69746E65 0x00000001 0x00100F42 0x01020800 0x00802009 0x178BFBFF 0x00000002 0x00000000 0x00000000 0x00000000 0x00000000 0x00000003 0x00000000 0x00000000 0x00000000 0x00000000 0x00000004 0x00000000 0x00000000 0x00000000 0x00000000 0x00000005 0x00000040 0x00000040 0x00000003 0x00000000 [...] Chipset ------------------------------------------------------------------------- Northbridge AMD 790GX rev. 00 Southbridge ATI SB750 rev. 00 Memory Type DDR3 Memory Size 4096 MBytes Channels Dual, (Unganged) Memory Frequency 669.0 MHz (3:10) CAS# latency (CL) 9.0 RAS# to CAS# delay (tRCD) 9 RAS# Precharge (tRP) 9 Cycle Time (tRAS) 24 Bank Cycle Time (tRC) 33 Command Rate (CR) 1T Uncore Frequency 2006.9 MHz Memory SPD ------------------------------------------------------------------------- DIMM # 1 SMBus address 0x50 Memory type DDR3 Module format UDIMM Manufacturer (ID) G.Skill (7F7F7F7FCD000000) Size 2048 MBytes Max bandwidth PC3-10700 (667 MHz) Part number F3-10600CL9-2GBNT Number of banks 8 Nominal Voltage 1.50 Volts EPP no XMP no JEDEC timings table CL-tRCD-tRP-tRAS-tRC @ frequency JEDEC #1 6.0-6-6-17-23 @ 457 MHz JEDEC #2 7.0-7-7-20-27 @ 533 MHz JEDEC #3 8.0-8-8-22-31 @ 609 MHz JEDEC #4 9.0-9-9-25-34 @ 685 MHz DIMM # 2 SMBus address 0x51 Memory type DDR3 Module format UDIMM Manufacturer (ID) G.Skill (7F7F7F7FCD000000) Size 2048 MBytes Max bandwidth PC3-10700 (667 MHz) Part number F3-10600CL9-2GBNT Number of banks 8 Nominal Voltage 1.50 Volts EPP no XMP no JEDEC timings table CL-tRCD-tRP-tRAS-tRC @ frequency JEDEC #1 6.0-6-6-17-23 @ 457 MHz JEDEC #2 7.0-7-7-20-27 @ 533 MHz JEDEC #3 8.0-8-8-22-31 @ 609 MHz JEDEC #4 9.0-9-9-25-34 @ 685 MHz DIMM # 1 SPD registers [...] DIMM # 2 SPD registers [...] Monitoring ------------------------------------------------------------------------- Mainboard Model M4A78T-E (0x000001F7 - 0x00A955E4) LPCIO ------------------------------------------------------------------------- LPCIO Vendor ITE LPCIO Model IT8720 LPCIO Vendor ID 0x90 LPCIO Chip ID 0x8720 LPCIO Revision ID 0x2 Config Mode I/O address 0x2E Config Mode LDN 0x4 Config Mode registers [...] Register space LPC, base address = 0x0290 Hardware Monitors ------------------------------------------------------------------------- Hardware monitor ITE IT87 Voltage 1 1.62 Volts [0x65] (VIN1) Voltage 2 1.15 Volts [0x48] (CPU VCORE) Voltage 3 5.03 Volts [0xBB] (+5V) Voltage 8 3.34 Volts [0xD1] (VBAT) Temperature 0 39°C (102°F) [0x27] (TMPIN0) Temperature 1 43°C (109°F) [0x2B] (TMPIN1) Fan 0 3096 RPM [0xDA] (FANIN0) Register space LPC, base address = 0x0290 [...] Hardware monitor AMD SB6xx/7xx Voltage 0 1.37 Volts [0x1D2] (CPU VCore) Voltage 1 3.50 Volts [0x27B] (CPU IO) Voltage 2 12.68 Volts [0x282] (+12V) Hardware monitor AMD Phenom II X2 550 Power 0 89.10 W (Processor) Temperature 0 35°C (94°F) [0x115] (Core #0) Temperature 1 35°C (94°F) [0x115] (Core #1)

    Read the article

  • C#/.NET Little Wonders: The ConcurrentDictionary

    - by James Michael Hare
    Once again we consider some of the lesser known classes and keywords of C#.  In this series of posts, we will discuss how the concurrent collections have been developed to help alleviate these multi-threading concerns.  Last week’s post began with a general introduction and discussed the ConcurrentStack<T> and ConcurrentQueue<T>.  Today's post discusses the ConcurrentDictionary<T> (originally I had intended to discuss ConcurrentBag this week as well, but ConcurrentDictionary had enough information to create a very full post on its own!).  Finally next week, we shall close with a discussion of the ConcurrentBag<T> and BlockingCollection<T>. For more of the "Little Wonders" posts, see the index here. Recap As you'll recall from the previous post, the original collections were object-based containers that accomplished synchronization through a Synchronized member.  While these were convenient because you didn't have to worry about writing your own synchronization logic, they were a bit too finely grained and if you needed to perform multiple operations under one lock, the automatic synchronization didn't buy much. With the advent of .NET 2.0, the original collections were succeeded by the generic collections which are fully type-safe, but eschew automatic synchronization.  This cuts both ways in that you have a lot more control as a developer over when and how fine-grained you want to synchronize, but on the other hand if you just want simple synchronization it creates more work. With .NET 4.0, we get the best of both worlds in generic collections.  A new breed of collections was born called the concurrent collections in the System.Collections.Concurrent namespace.  These amazing collections are fine-tuned to have best overall performance for situations requiring concurrent access.  They are not meant to replace the generic collections, but to simply be an alternative to creating your own locking mechanisms. Among those concurrent collections were the ConcurrentStack<T> and ConcurrentQueue<T> which provide classic LIFO and FIFO collections with a concurrent twist.  As we saw, some of the traditional methods that required calls to be made in a certain order (like checking for not IsEmpty before calling Pop()) were replaced in favor of an umbrella operation that combined both under one lock (like TryPop()). Now, let's take a look at the next in our series of concurrent collections!For some excellent information on the performance of the concurrent collections and how they perform compared to a traditional brute-force locking strategy, see this wonderful whitepaper by the Microsoft Parallel Computing Platform team here. ConcurrentDictionary – the fully thread-safe dictionary The ConcurrentDictionary<TKey,TValue> is the thread-safe counterpart to the generic Dictionary<TKey, TValue> collection.  Obviously, both are designed for quick – O(1) – lookups of data based on a key.  If you think of algorithms where you need lightning fast lookups of data and don’t care whether the data is maintained in any particular ordering or not, the unsorted dictionaries are generally the best way to go. Note: as a side note, there are sorted implementations of IDictionary, namely SortedDictionary and SortedList which are stored as an ordered tree and a ordered list respectively.  While these are not as fast as the non-sorted dictionaries – they are O(log2 n) – they are a great combination of both speed and ordering -- and still greatly outperform a linear search. Now, once again keep in mind that if all you need to do is load a collection once and then allow multi-threaded reading you do not need any locking.  Examples of this tend to be situations where you load a lookup or translation table once at program start, then keep it in memory for read-only reference.  In such cases locking is completely non-productive. However, most of the time when we need a concurrent dictionary we are interleaving both reads and updates.  This is where the ConcurrentDictionary really shines!  It achieves its thread-safety with no common lock to improve efficiency.  It actually uses a series of locks to provide concurrent updates, and has lockless reads!  This means that the ConcurrentDictionary gets even more efficient the higher the ratio of reads-to-writes you have. ConcurrentDictionary and Dictionary differences For the most part, the ConcurrentDictionary<TKey,TValue> behaves like it’s Dictionary<TKey,TValue> counterpart with a few differences.  Some notable examples of which are: Add() does not exist in the concurrent dictionary. This means you must use TryAdd(), AddOrUpdate(), or GetOrAdd().  It also means that you can’t use a collection initializer with the concurrent dictionary. TryAdd() replaced Add() to attempt atomic, safe adds. Because Add() only succeeds if the item doesn’t already exist, we need an atomic operation to check if the item exists, and if not add it while still under an atomic lock. TryUpdate() was added to attempt atomic, safe updates. If we want to update an item, we must make sure it exists first and that the original value is what we expected it to be.  If all these are true, we can update the item under one atomic step. TryRemove() was added to attempt atomic, safe removes. To safely attempt to remove a value we need to see if the key exists first, this checks for existence and removes under an atomic lock. AddOrUpdate() was added to attempt an thread-safe “upsert”. There are many times where you want to insert into a dictionary if the key doesn’t exist, or update the value if it does.  This allows you to make a thread-safe add-or-update. GetOrAdd() was added to attempt an thread-safe query/insert. Sometimes, you want to query for whether an item exists in the cache, and if it doesn’t insert a starting value for it.  This allows you to get the value if it exists and insert if not. Count, Keys, Values properties take a snapshot of the dictionary. Accessing these properties may interfere with add and update performance and should be used with caution. ToArray() returns a static snapshot of the dictionary. That is, the dictionary is locked, and then copied to an array as a O(n) operation.  GetEnumerator() is thread-safe and efficient, but allows dirty reads. Because reads require no locking, you can safely iterate over the contents of the dictionary.  The only downside is that, depending on timing, you may get dirty reads. Dirty reads during iteration The last point on GetEnumerator() bears some explanation.  Picture a scenario in which you call GetEnumerator() (or iterate using a foreach, etc.) and then, during that iteration the dictionary gets updated.  This may not sound like a big deal, but it can lead to inconsistent results if used incorrectly.  The problem is that items you already iterated over that are updated a split second after don’t show the update, but items that you iterate over that were updated a split second before do show the update.  Thus you may get a combination of items that are “stale” because you iterated before the update, and “fresh” because they were updated after GetEnumerator() but before the iteration reached them. Let’s illustrate with an example, let’s say you load up a concurrent dictionary like this: 1: // load up a dictionary. 2: var dictionary = new ConcurrentDictionary<string, int>(); 3:  4: dictionary["A"] = 1; 5: dictionary["B"] = 2; 6: dictionary["C"] = 3; 7: dictionary["D"] = 4; 8: dictionary["E"] = 5; 9: dictionary["F"] = 6; Then you have one task (using the wonderful TPL!) to iterate using dirty reads: 1: // attempt iteration in a separate thread 2: var iterationTask = new Task(() => 3: { 4: // iterates using a dirty read 5: foreach (var pair in dictionary) 6: { 7: Console.WriteLine(pair.Key + ":" + pair.Value); 8: } 9: }); And one task to attempt updates in a separate thread (probably): 1: // attempt updates in a separate thread 2: var updateTask = new Task(() => 3: { 4: // iterates, and updates the value by one 5: foreach (var pair in dictionary) 6: { 7: dictionary[pair.Key] = pair.Value + 1; 8: } 9: }); Now that we’ve done this, we can fire up both tasks and wait for them to complete: 1: // start both tasks 2: updateTask.Start(); 3: iterationTask.Start(); 4:  5: // wait for both to complete. 6: Task.WaitAll(updateTask, iterationTask); Now, if I you didn’t know about the dirty reads, you may have expected to see the iteration before the updates (such as A:1, B:2, C:3, D:4, E:5, F:6).  However, because the reads are dirty, we will quite possibly get a combination of some updated, some original.  My own run netted this result: 1: F:6 2: E:6 3: D:5 4: C:4 5: B:3 6: A:2 Note that, of course, iteration is not in order because ConcurrentDictionary, like Dictionary, is unordered.  Also note that both E and F show the value 6.  This is because the output task reached F before the update, but the updates for the rest of the items occurred before their output (probably because console output is very slow, comparatively). If we want to always guarantee that we will get a consistent snapshot to iterate over (that is, at the point we ask for it we see precisely what is in the dictionary and no subsequent updates during iteration), we should iterate over a call to ToArray() instead: 1: // attempt iteration in a separate thread 2: var iterationTask = new Task(() => 3: { 4: // iterates using a dirty read 5: foreach (var pair in dictionary.ToArray()) 6: { 7: Console.WriteLine(pair.Key + ":" + pair.Value); 8: } 9: }); The atomic Try…() methods As you can imagine TryAdd() and TryRemove() have few surprises.  Both first check the existence of the item to determine if it can be added or removed based on whether or not the key currently exists in the dictionary: 1: // try add attempts an add and returns false if it already exists 2: if (dictionary.TryAdd("G", 7)) 3: Console.WriteLine("G did not exist, now inserted with 7"); 4: else 5: Console.WriteLine("G already existed, insert failed."); TryRemove() also has the virtue of returning the value portion of the removed entry matching the given key: 1: // attempt to remove the value, if it exists it is removed and the original is returned 2: int removedValue; 3: if (dictionary.TryRemove("C", out removedValue)) 4: Console.WriteLine("Removed C and its value was " + removedValue); 5: else 6: Console.WriteLine("C did not exist, remove failed."); Now TryUpdate() is an interesting creature.  You might think from it’s name that TryUpdate() first checks for an item’s existence, and then updates if the item exists, otherwise it returns false.  Well, note quite... It turns out when you call TryUpdate() on a concurrent dictionary, you pass it not only the new value you want it to have, but also the value you expected it to have before the update.  If the item exists in the dictionary, and it has the value you expected, it will update it to the new value atomically and return true.  If the item is not in the dictionary or does not have the value you expected, it is not modified and false is returned. 1: // attempt to update the value, if it exists and if it has the expected original value 2: if (dictionary.TryUpdate("G", 42, 7)) 3: Console.WriteLine("G existed and was 7, now it's 42."); 4: else 5: Console.WriteLine("G either didn't exist, or wasn't 7."); The composite Add methods The ConcurrentDictionary also has composite add methods that can be used to perform updates and gets, with an add if the item is not existing at the time of the update or get. The first of these, AddOrUpdate(), allows you to add a new item to the dictionary if it doesn’t exist, or update the existing item if it does.  For example, let’s say you are creating a dictionary of counts of stock ticker symbols you’ve subscribed to from a market data feed: 1: public sealed class SubscriptionManager 2: { 3: private readonly ConcurrentDictionary<string, int> _subscriptions = new ConcurrentDictionary<string, int>(); 4:  5: // adds a new subscription, or increments the count of the existing one. 6: public void AddSubscription(string tickerKey) 7: { 8: // add a new subscription with count of 1, or update existing count by 1 if exists 9: var resultCount = _subscriptions.AddOrUpdate(tickerKey, 1, (symbol, count) => count + 1); 10:  11: // now check the result to see if we just incremented the count, or inserted first count 12: if (resultCount == 1) 13: { 14: // subscribe to symbol... 15: } 16: } 17: } Notice the update value factory Func delegate.  If the key does not exist in the dictionary, the add value is used (in this case 1 representing the first subscription for this symbol), but if the key already exists, it passes the key and current value to the update delegate which computes the new value to be stored in the dictionary.  The return result of this operation is the value used (in our case: 1 if added, existing value + 1 if updated). Likewise, the GetOrAdd() allows you to attempt to retrieve a value from the dictionary, and if the value does not currently exist in the dictionary it will insert a value.  This can be handy in cases where perhaps you wish to cache data, and thus you would query the cache to see if the item exists, and if it doesn’t you would put the item into the cache for the first time: 1: public sealed class PriceCache 2: { 3: private readonly ConcurrentDictionary<string, double> _cache = new ConcurrentDictionary<string, double>(); 4:  5: // adds a new subscription, or increments the count of the existing one. 6: public double QueryPrice(string tickerKey) 7: { 8: // check for the price in the cache, if it doesn't exist it will call the delegate to create value. 9: return _cache.GetOrAdd(tickerKey, symbol => GetCurrentPrice(symbol)); 10: } 11:  12: private double GetCurrentPrice(string tickerKey) 13: { 14: // do code to calculate actual true price. 15: } 16: } There are other variations of these two methods which vary whether a value is provided or a factory delegate, but otherwise they work much the same. Oddities with the composite Add methods The AddOrUpdate() and GetOrAdd() methods are totally thread-safe, on this you may rely, but they are not atomic.  It is important to note that the methods that use delegates execute those delegates outside of the lock.  This was done intentionally so that a user delegate (of which the ConcurrentDictionary has no control of course) does not take too long and lock out other threads. This is not necessarily an issue, per se, but it is something you must consider in your design.  The main thing to consider is that your delegate may get called to generate an item, but that item may not be the one returned!  Consider this scenario: A calls GetOrAdd and sees that the key does not currently exist, so it calls the delegate.  Now thread B also calls GetOrAdd and also sees that the key does not currently exist, and for whatever reason in this race condition it’s delegate completes first and it adds its new value to the dictionary.  Now A is done and goes to get the lock, and now sees that the item now exists.  In this case even though it called the delegate to create the item, it will pitch it because an item arrived between the time it attempted to create one and it attempted to add it. Let’s illustrate, assume this totally contrived example program which has a dictionary of char to int.  And in this dictionary we want to store a char and it’s ordinal (that is, A = 1, B = 2, etc).  So for our value generator, we will simply increment the previous value in a thread-safe way (perhaps using Interlocked): 1: public static class Program 2: { 3: private static int _nextNumber = 0; 4:  5: // the holder of the char to ordinal 6: private static ConcurrentDictionary<char, int> _dictionary 7: = new ConcurrentDictionary<char, int>(); 8:  9: // get the next id value 10: public static int NextId 11: { 12: get { return Interlocked.Increment(ref _nextNumber); } 13: } Then, we add a method that will perform our insert: 1: public static void Inserter() 2: { 3: for (int i = 0; i < 26; i++) 4: { 5: _dictionary.GetOrAdd((char)('A' + i), key => NextId); 6: } 7: } Finally, we run our test by starting two tasks to do this work and get the results… 1: public static void Main() 2: { 3: // 3 tasks attempting to get/insert 4: var tasks = new List<Task> 5: { 6: new Task(Inserter), 7: new Task(Inserter) 8: }; 9:  10: tasks.ForEach(t => t.Start()); 11: Task.WaitAll(tasks.ToArray()); 12:  13: foreach (var pair in _dictionary.OrderBy(p => p.Key)) 14: { 15: Console.WriteLine(pair.Key + ":" + pair.Value); 16: } 17: } If you run this with only one task, you get the expected A:1, B:2, ..., Z:26.  But running this in parallel you will get something a bit more complex.  My run netted these results: 1: A:1 2: B:3 3: C:4 4: D:5 5: E:6 6: F:7 7: G:8 8: H:9 9: I:10 10: J:11 11: K:12 12: L:13 13: M:14 14: N:15 15: O:16 16: P:17 17: Q:18 18: R:19 19: S:20 20: T:21 21: U:22 22: V:23 23: W:24 24: X:25 25: Y:26 26: Z:27 Notice that B is 3?  This is most likely because both threads attempted to call GetOrAdd() at roughly the same time and both saw that B did not exist, thus they both called the generator and one thread got back 2 and the other got back 3.  However, only one of those threads can get the lock at a time for the actual insert, and thus the one that generated the 3 won and the 3 was inserted and the 2 got discarded.  This is why on these methods your factory delegates should be careful not to have any logic that would be unsafe if the value they generate will be pitched in favor of another item generated at roughly the same time.  As such, it is probably a good idea to keep those generators as stateless as possible. Summary The ConcurrentDictionary is a very efficient and thread-safe version of the Dictionary generic collection.  It has all the benefits of type-safety that it’s generic collection counterpart does, and in addition is extremely efficient especially when there are more reads than writes concurrently. Tweet Technorati Tags: C#, .NET, Concurrent Collections, Collections, Little Wonders, Black Rabbit Coder,James Michael Hare

    Read the article

  • Using INotifyPropertyChanged in background threads

    - by digitaldias
    Following up on a previous blog post where I exemplify databinding to objects, a reader was having some trouble with getting the UI to update. Here’s the rough UI: The idea is, when pressing Start, a background worker process starts ticking at the specified interval, then proceeds to increment the databound Elapsed value. The problem is that event propagation is limeted to current thread, meaning, you fire an event in one thread, then other threads of the same application will not catch it. The Code behind So, somewhere in my ViewModel, I have a corresponding bethod Start that initiates a background worker, for example: public void Start( ) { BackgroundWorker backgroundWorker = new BackgroundWorker( ); backgroundWorker.DoWork += IncrementTimerValue; backgroundWorker.RunWorkerAsync( ); } protected void IncrementTimerValue( object sender, DoWorkEventArgs e ) { do { if( this.ElapsedMs == 100 ) this.ElapsedMs = 0; else this.ElapsedMs++; }while( true ); } Assuming that there is a property: public int ElapsedMs { get { return _elapsedMs; } set { if( _elapsedMs == value ) return; _elapsedMs = value; NotifyThatPropertyChanged( "ElapsedMs" ); } } The above code will not work. If you step into this code in debug, you will find that INotifyPropertyChanged is called, but it does so in a different thread, and thus the UI never catches it, and does not update. One solution Knowing that the background thread updates the ElapsedMs member gives me a chance to activate BackgroundWorker class’ progress reporting mechanism to simply alert the main thread that something has happened, and that it is probably a good idea to refresh the ElapsedMs binding. public void Start( ) { BackgroundWorker backgroundWorker = new BackgroundWorker( ); backgroundWorker.DoWork += IncrementTimerValue; // Listen for progress report events backgroundWorker.WorkerReportsProgress = true; // Tell the UI that ElapsedMs needs to update backgroundWorker.RunWorkerCompleted += ( sender, e ) => { NotifyThatPropertyChanged( "ElapsedMs" ) }; backgroundWorker.RunWorkerAsync( ); } protected void IncrementTimerValue( object sender, DoWorkEventArgs e ) { do { if( this.ElapsedMs == 100 ) this.ElapsedMs = 0; else this.ElapsedMs++; // report any progress ( sender as BackgroundWorker ).ReportProgress( 0 ); }while( true ); } What happens above now is that I’ve used the BackgroundWorker cross thread mechanism to alert me of when it is ok for the UI to update it’s ElapsedMs field. Because the property itself is being updated in a different thread, I’m removing the NotifyThatPropertyChanged call from it’s Set method, and moving that responsability to the anonymous method that I created in the Start method. This is one way of solving the issue of having a background thread update your UI. I would be happy to hear of other cross-threading mechanisms for working in a MCP/MVC/MVVM pattern.

    Read the article

  • Synergy 1.5 crash (OSX 10.6.8)

    - by Oliver
    THANKS FOR TAKING THE TIME TO READ THIS I recently installed Synergy 1.5 r2278 (for Mac OSX 10.6.8) and was using it fine for most of the day, then it decided to stop working (the only thing I changed systemwise was the screensaver - and then after it started crashing disabled it - to see if it would resolve). When I start Synergy (on the Mac - Client) it says: after about 5 seconds (and successfully connecting to the Server) "synergyc quit unexpectedly" Here is the crash log (w/ binery info removed - too long for post requirements) Process: synergyc [1026] Path: /Applications/Synergy.app/Contents/MacOS/synergyc Identifier: synergy Version: ??? (???) Code Type: X86 (Native) Parent Process: Synergy [1023] Date/Time: 2014-05-28 15:36:17.746 +0930 OS Version: Mac OS X 10.6.8 (10K549) Report Version: 6 Interval Since Last Report: 2144189 sec Crashes Since Last Report: 23 Per-App Interval Since Last Report: 10242 sec Per-App Crashes Since Last Report: 9 Anonymous UUID: 86D5A57C-13D4-470E-AC72-48ACDDDE5EB0 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Crashed Thread: 5 Application Specific Information: abort() called Thread 0: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x95cf3afa mach_msg_trap + 10 1 libSystem.B.dylib 0x95cf4267 mach_msg + 68 2 com.apple.CoreFoundation 0x95af02df __CFRunLoopRun + 2079 3 com.apple.CoreFoundation 0x95aef3c4 CFRunLoopRunSpecific + 452 4 com.apple.CoreFoundation 0x95aef1f1 CFRunLoopRunInMode + 97 5 com.apple.HIToolbox 0x93654e04 RunCurrentEventLoopInMode + 392 6 com.apple.HIToolbox 0x93654bb9 ReceiveNextEventCommon + 354 7 com.apple.HIToolbox 0x937dd137 ReceiveNextEvent + 83 8 synergyc 0x000356d0 COSXEventQueueBuffer::waitForEvent(double) + 48 9 synergyc 0x00010dd5 CEventQueue::getEvent(CEvent&, double) + 325 10 synergyc 0x00011fb0 CEventQueue::loop() + 272 11 synergyc 0x00044eb6 CClientApp::mainLoop() + 134 12 synergyc 0x0005c509 standardStartupStatic(int, char**) + 41 13 synergyc 0x000448a9 CClientApp::runInner(int, char**, ILogOutputter*, int (*)(int, char**)) + 137 14 synergyc 0x0005c4b0 CAppUtilUnix::run(int, char**) + 64 15 synergyc 0x000427df CApp::run(int, char**) + 63 16 synergyc 0x00006e65 main + 117 17 synergyc 0x00006dd9 start + 53 Thread 1: 0 libSystem.B.dylib 0x95d607da __sigwait + 10 1 libSystem.B.dylib 0x95d607b6 sigwait$UNIX2003 + 71 2 synergyc 0x00009583 CArchMultithreadPosix::threadSignalHandler(void*) + 67 3 libSystem.B.dylib 0x95d21259 _pthread_start + 345 4 libSystem.B.dylib 0x95d210de thread_start + 34 Thread 2: 0 libSystem.B.dylib 0x95d21aa2 __semwait_signal + 10 1 libSystem.B.dylib 0x95d2175e _pthread_cond_wait + 1191 2 libSystem.B.dylib 0x95d212b1 pthread_cond_timedwait$UNIX2003 + 72 3 synergyc 0x00009476 CArchMultithreadPosix::waitCondVar(CArchCondImpl*, CArchMutexImpl*, double) + 150 4 synergyc 0x0002b18f CCondVarBase::wait(double) const + 63 5 synergyc 0x0002ce68 CSocketMultiplexer::serviceThread(void*) + 136 6 synergyc 0x0002d698 TMethodJob<CSocketMultiplexer>::run() + 40 7 synergyc 0x0002b8f4 CThread::threadFunc(void*) + 132 8 synergyc 0x00008f30 CArchMultithreadPosix::doThreadFunc(CArchThreadImpl*) + 80 9 synergyc 0x0000902a CArchMultithreadPosix::threadFunc(void*) + 74 10 libSystem.B.dylib 0x95d21259 _pthread_start + 345 11 libSystem.B.dylib 0x95d210de thread_start + 34 Thread 3: Dispatch queue: com.apple.libdispatch-manager 0 libSystem.B.dylib 0x95d1a382 kevent + 10 1 libSystem.B.dylib 0x95d1aa9c _dispatch_mgr_invoke + 215 2 libSystem.B.dylib 0x95d19f59 _dispatch_queue_invoke + 163 3 libSystem.B.dylib 0x95d19cfe _dispatch_worker_thread2 + 240 4 libSystem.B.dylib 0x95d19781 _pthread_wqthread + 390 5 libSystem.B.dylib 0x95d195c6 start_wqthread + 30 Thread 4: 0 libSystem.B.dylib 0x95d19412 __workq_kernreturn + 10 1 libSystem.B.dylib 0x95d199a8 _pthread_wqthread + 941 2 libSystem.B.dylib 0x95d195c6 start_wqthread + 30 Thread 5 Crashed: 0 libSystem.B.dylib 0x95d610ee __semwait_signal_nocancel + 10 1 libSystem.B.dylib 0x95d60fd2 nanosleep$NOCANCEL$UNIX2003 + 166 2 libSystem.B.dylib 0x95ddbfb2 usleep$NOCANCEL$UNIX2003 + 61 3 libSystem.B.dylib 0x95dfd6f0 abort + 105 4 libSystem.B.dylib 0x95d79b1b _Unwind_Resume + 59 5 synergyc 0x00008fd1 CArchMultithreadPosix::doThreadFunc(CArchThreadImpl*) + 241 6 synergyc 0x0000902a CArchMultithreadPosix::threadFunc(void*) + 74 7 libSystem.B.dylib 0x95d21259 _pthread_start + 345 8 libSystem.B.dylib 0x95d210de thread_start + 34 Thread 5 crashed with X86 Thread State (32-bit): eax: 0x0000003c ebx: 0x95d60f39 ecx: 0xb0288a7c edx: 0x95d610ee edi: 0x00521950 esi: 0xb0288ad8 ebp: 0xb0288ab8 esp: 0xb0288a7c ss: 0x0000001f efl: 0x00000247 eip: 0x95d610ee cs: 0x00000007 ds: 0x0000001f es: 0x0000001f fs: 0x0000001f gs: 0x00000037 cr2: 0x002fe000 Model: MacBook2,1, BootROM MB21.00A5.B07, 2 processors, Intel Core 2 Duo, 2.16 GHz, 2 GB

    Read the article

  • Why would delaying a thread response fix view corruption?

    - by Beth S
    6 times out of 10 my very simple iPhone app is getting a corrupted display on launch or crashes randomly. But it behaves fine in the simulator. The display corruption looks like mis-colored fonts, out of place font text, wrong background colors, etc. I've found a strange work-around.. when my thread delays by 2 seconds before calling the "done" notification, everything works swimmingly. The thread reads a web page and the "done" notification loads up a PickerView with strings. So what gives? Can I not safely initiate a threaded task from viewDidLoad? - (void) loadWebPage:(NSString *)urlAddition { NSAutoreleasePool *subPool = [[NSAutoreleasePool alloc] init]; NSString *pageSource; NSError *err; NSString *urlString = [NSString stringWithString:@"http://server/%@", urlAddition]; pageSource = [NSString stringWithContentsOfURL:[NSURL URLWithString: urlString] encoding:NSUTF8StringEncoding error:&err]; [NSThread sleepForTimeInterval:2.0]; // THIS STOPS THE DISPLAY CORRUPTION [[NSNotificationCenter defaultCenter] postNotificationName:@"webDoneNotification" object:nil]; [subPool drain]; } - (void) webDoneNotification: (NSNotification *)pNotification { [mediaArray release]; mediaArray = [[NSArray arrayWithObjects: [NSString stringWithString:@"new pickerview text"], nil] retain]; [mediaPickerView reloadAllComponents]; [mediaPickerView selectRow:0 inComponent:0 animated:NO]; } - (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil { mediaArray = [[NSArray arrayWithObjects: [NSString stringWithString:@"init pickerview text"], nil] retain]; if (self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil]) { // Custom initialization } return self; } - (void)viewDidLoad { [super viewDidLoad]; myWebThread = [[WebThread alloc] initWithDelegate:self]; [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(webDoneNotification:) name:@"webDoneNotification" object:nil]; [myWebThread performSelectorInBackground:@selector(loadWebPage:) withObject:@""]; } Thanks! Update: Even a delay of 0.1 seconds is enough to completely fix the problem.

    Read the article

  • What is an efficient strategy for multiple threads posting jobs and waiting for response from a single thread?

    - by jakewins
    In java, what is an efficient solution to the following problem: I have multiple threads (10-20 or so) generating jobs ("Job Creators"), and a single thread capable of performing them ("The worker"). Once a job creator has posted a job, it should wait for the job to finish, yielding no result other than "it's done", before it keeps going. For sending the jobs to the worker thread, I think a ring buffer or similar standard fan-in setup would perhaps be a good approach? But for a Job Creator to find out that her job has been done, I'm not so sure.. The job creators could sleep, and the worker interrupt them when done.. Or each job creator could have an atomic boolean that it checks, and that the worker sets. I dunno, neither of those feel very nice. I'd like to do it with as few (none, if possible) locks as absolutely possible. So to be clear: What I'm looking for is speed, not necessarily simplicity. Does anyone have any suggestions? Links to reading about concurrency strategies would also be very welcome!

    Read the article

  • Why there is no scoped locks for multiple mutexes in C++0x or Boost.Thread?

    - by Vicente Botet Escriba
    C++0x thread library or Boost.thread define non-member variadic template function that lock all lock avoiding dead lock. template <class L1, class L2, class... L3> void lock(L1&, L2&, L3&...); While this function avoid help to deadlock, the standard do not includes the associated scoped lock to write exception safe code. { std::lock(l1,l2); // do some thing // unlock li l2 exception safe } That means that we need to use other mechanism as try-catch block to make exception safe code or define our own scoped lock on multiple mutexes ourselves or even do that { std::lock(l1,l2); std::unique_lock lk1(l1, std::adopted); std::unique_lock lk2(l2, std::adopted); // do some thing // unlock li l2 on destruction of lk1 lk2 } Why the standard doesn't includes a scoped lock on multiple mutexes of the same type, as for example { std::array_unique_lock<std::mutex> lk(l1,l2); // do some thing // unlock l1 l2 on destruction of lk } or tuples of mutexes { std::tuple_unique_lock<std::mutex, std::recursive_mutex> lk(l1,l2); // do some thing // unlock l1 l2 on destruction of lk } Is there something wrong on the design?

    Read the article

  • Why onCreate() calling multiple times when i use Thread()?

    - by RajaReddy PolamReddy
    In my app i faced a problem with threads. i am using native code in my app. i try to load library and then calling native functions from the android code. 1. By using Threads() : PjsuaThread pjsuaThread = new PjsuaThread(); pjsuaThread.start(); thread code class PjsuaThread extends Thread { public void run() { if (pjsua_app.initApp() != 0) { // native function calling return; } else { } pjsua_app.startPjsua(ApjsuaActivity.CFG_FNAME); // native function calling finished = true; } When i use code like this, onCreate() function calling multiple times and able to load library and calling some functions properly, after some seconds onCreate calling again because of that it's crashing. 2. Using AsyncTask(): And also i used AsyncTask< for this requirement, it's crashing the application( crashing in lib code ). not able to open any functions class SipTask extends AsyncTask<Void, String, Void> { protected Void doInBackground(Void... args) { if (pjsua_app.initApp() != 0) { return null; } else { } pjsua_app.startPjsua(ApjsuaActivity.CFG_FNAME); finished = true; return null; } @Override protected void onPostExecute(Void result) { super.onPostExecute(result); Log.i(TAG, "On POst "); } } What is annoying is that in most cases it is not the missing library, it's tried to able to load the lib crashing in between. any one know the reason ?

    Read the article

  • How can I get back into my main processing thread?

    - by daveomcd
    I have an app that I'm accessing a remote website with NSURLConnection to run some code and then save out some XML files. I am then accessing those XML Files and parsing through them for information. The process works fine except that my User Interface isn't getting updated properly. I want to keep the user updated through my UILabel. I'm trying to update the text by using setBottomBarToUpdating:. It works the first time when I set it to "Processing Please Wait..."; however, in the connectionDidFinishLoading: it doesn't update. I'm thinking my NSURLConnection is running on a separate thread and my attempt with the dispatch_get_main_queue to update on the main thread isn't working. How can I alter my code to resolve this? Thanks! [If I need to include more information/code just let me know!] myFile.m NSLog(@"Refreshing..."); dispatch_sync( dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ [self getResponse:@"http://mylocation/path/to/file.aspx"]; }); [self setBottomBarToUpdating:@"Processing Please Wait..."]; queue = dispatch_queue_create("updateQueue", DISPATCH_QUEUE_CONCURRENT); connectionDidFinishLoading: if ([response rangeOfString:@"Complete"].location == NSNotFound]) { // failed } else { //success dispatch_async(dispatch_get_main_queue(),^ { [self setBottomBarToUpdating:@"Updating Contacts..."]; }); [self updateFromXMLFile:@"http://thislocation.com/path/to/file.xml"]; dispatch_async(dispatch_get_main_queue(),^ { [self setBottomBarToUpdating:@"Updating Emails..."]; }); [self updateFromXMLFile:@"http://thislocation.com/path/to/file2.xml"]; }

    Read the article

  • Qthread - trouble shutting down threads

    - by Bryan Greenway
    For the last few days, I've been trying out the new preferred approach for using QThreads without subclassing QThread. The trouble I'm having is when I try to shutdown a set of threads that I created. I regularly get a "Destroyed while thread is still running" message (if I'm running in Debug mode, I also get a Segmentation Fault dialog). My code is very simple, and I've tried to follow the examples that I've been able to find on the internet. My basic setup is as follows: I've a simple class that I want to run in a separate thread; in fact, I want to run 5 instances of this class, each in a separate thread. I have a simple dialog with a button to start each thread, and a button to stop each thread (10 buttons). When I click one of the "start" buttons, a new instance of the test class is created, a new QThread is created, a movetothread is called to get the test class object to the thread...also, since I have a couple of other members in the test class that need to move to the thread, I call movetothread a few additional times with these other items. Note that one of these items is a QUdpSocket, and although this may not make sense, I wanted to make sure that sockets could be moved to a separate thread in this fashion...I haven't tested the use of the socket in the thread at this point. Starting of the threads all seem to work fine. When I use the linux top command to see if the threads are created and running, they show up as expected. The problem occurs when I begin stopping the threads. I randomly (or it appears to be random) get the error described above. Class that is to run in separate thread: // Declaration class TestClass : public QObject { Q_OBJECT public: explicit TestClass(QObject *parent = 0); QTimer m_workTimer; QUdpSocket m_socket; Q_SIGNALS: void finished(); public Q_SLOTS: void start(); void stop(); void doWork(); }; // Implementation TestClass::TestClass(QObject *parent) : QObject(parent) { } void TestClass::start() { connect(&m_workTimer, SIGNAL(timeout()),this,SLOT(doWork())); m_workTimer.start(50); } void TestClass::stop() { m_workTimer.stop(); emit finished(); } void TestClass::doWork() { int j; for(int i = 0; i<10000; i++) { j = i; } } Inside my main app, code called to start the first thread (similar code exists for each of the other threads): mp_thread1 = new QThread(); mp_testClass1 = new TestClass(); mp_testClass1->moveToThread(mp_thread1); mp_testClass1->m_socket.moveToThread(mp_thread1); mp_testClass1->m_workTimer.moveToThread(mp_thread1); connect(mp_thread1, SIGNAL(started()), mp_testClass1, SLOT(start())); connect(mp_testClass1, SIGNAL(finished()), mp_thread1, SLOT(quit())); connect(mp_testClass1, SIGNAL(finished()), mp_testClass1, SLOT(deleteLater())); connect(mp_testClass1, SIGNAL(finished()), mp_thread1, SLOT(deleteLater())); connect(this,SIGNAL(stop1()),mp_testClass1,SLOT(stop())); mp_thread1->start(); Also inside my main app, this code is called when a stop button is clicked for a specific thread (in this case thread 1): emit stop1(); Sometimes it appears that threads are stopped and destroyed without issue. Other times, I get the error described above. Any guidance would be greatly appreciated. Thanks, Bryan

    Read the article

  • Parallelism in .NET – Part 4, Imperative Data Parallelism: Aggregation

    - by Reed
    In the article on simple data parallelism, I described how to perform an operation on an entire collection of elements in parallel.  Often, this is not adequate, as the parallel operation is going to be performing some form of aggregation. Simple examples of this might include taking the sum of the results of processing a function on each element in the collection, or finding the minimum of the collection given some criteria.  This can be done using the techniques described in simple data parallelism, however, special care needs to be taken into account to synchronize the shared data appropriately.  The Task Parallel Library has tools to assist in this synchronization. The main issue with aggregation when parallelizing a routine is that you need to handle synchronization of data.  Since multiple threads will need to write to a shared portion of data.  Suppose, for example, that we wanted to parallelize a simple loop that looked for the minimum value within a dataset: double min = double.MaxValue; foreach(var item in collection) { double value = item.PerformComputation(); min = System.Math.Min(min, value); } .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; } This seems like a good candidate for parallelization, but there is a problem here.  If we just wrap this into a call to Parallel.ForEach, we’ll introduce a critical race condition, and get the wrong answer.  Let’s look at what happens here: // Buggy code! Do not use! double min = double.MaxValue; Parallel.ForEach(collection, item => { double value = item.PerformComputation(); min = System.Math.Min(min, value); }); This code has a fatal flaw: min will be checked, then set, by multiple threads simultaneously.  Two threads may perform the check at the same time, and set the wrong value for min.  Say we get a value of 1 in thread 1, and a value of 2 in thread 2, and these two elements are the first two to run.  If both hit the min check line at the same time, both will determine that min should change, to 1 and 2 respectively.  If element 1 happens to set the variable first, then element 2 sets the min variable, we’ll detect a min value of 2 instead of 1.  This can lead to wrong answers. Unfortunately, fixing this, with the Parallel.ForEach call we’re using, would require adding locking.  We would need to rewrite this like: // Safe, but slow double min = double.MaxValue; // Make a "lock" object object syncObject = new object(); Parallel.ForEach(collection, item => { double value = item.PerformComputation(); lock(syncObject) min = System.Math.Min(min, value); }); This will potentially add a huge amount of overhead to our calculation.  Since we can potentially block while waiting on the lock for every single iteration, we will most likely slow this down to where it is actually quite a bit slower than our serial implementation.  The problem is the lock statement – any time you use lock(object), you’re almost assuring reduced performance in a parallel situation.  This leads to two observations I’ll make: When parallelizing a routine, try to avoid locks. That being said: Always add any and all required synchronization to avoid race conditions. These two observations tend to be opposing forces – we often need to synchronize our algorithms, but we also want to avoid the synchronization when possible.  Looking at our routine, there is no way to directly avoid this lock, since each element is potentially being run on a separate thread, and this lock is necessary in order for our routine to function correctly every time. However, this isn’t the only way to design this routine to implement this algorithm.  Realize that, although our collection may have thousands or even millions of elements, we have a limited number of Processing Elements (PE).  Processing Element is the standard term for a hardware element which can process and execute instructions.  This typically is a core in your processor, but many modern systems have multiple hardware execution threads per core.  The Task Parallel Library will not execute the work for each item in the collection as a separate work item. Instead, when Parallel.ForEach executes, it will partition the collection into larger “chunks” which get processed on different threads via the ThreadPool.  This helps reduce the threading overhead, and help the overall speed.  In general, the Parallel class will only use one thread per PE in the system. Given the fact that there are typically fewer threads than work items, we can rethink our algorithm design.  We can parallelize our algorithm more effectively by approaching it differently.  Because the basic aggregation we are doing here (Min) is communitive, we do not need to perform this in a given order.  We knew this to be true already – otherwise, we wouldn’t have been able to parallelize this routine in the first place.  With this in mind, we can treat each thread’s work independently, allowing each thread to serially process many elements with no locking, then, after all the threads are complete, “merge” together the results. This can be accomplished via a different set of overloads in the Parallel class: Parallel.ForEach<TSource,TLocal>.  The idea behind these overloads is to allow each thread to begin by initializing some local state (TLocal).  The thread will then process an entire set of items in the source collection, providing that state to the delegate which processes an individual item.  Finally, at the end, a separate delegate is run which allows you to handle merging that local state into your final results. To rewriting our routine using Parallel.ForEach<TSource,TLocal>, we need to provide three delegates instead of one.  The most basic version of this function is declared as: public static ParallelLoopResult ForEach<TSource, TLocal>( IEnumerable<TSource> source, Func<TLocal> localInit, Func<TSource, ParallelLoopState, TLocal, TLocal> body, Action<TLocal> localFinally ) The first delegate (the localInit argument) is defined as Func<TLocal>.  This delegate initializes our local state.  It should return some object we can use to track the results of a single thread’s operations. The second delegate (the body argument) is where our main processing occurs, although now, instead of being an Action<T>, we actually provide a Func<TSource, ParallelLoopState, TLocal, TLocal> delegate.  This delegate will receive three arguments: our original element from the collection (TSource), a ParallelLoopState which we can use for early termination, and the instance of our local state we created (TLocal).  It should do whatever processing you wish to occur per element, then return the value of the local state after processing is completed. The third delegate (the localFinally argument) is defined as Action<TLocal>.  This delegate is passed our local state after it’s been processed by all of the elements this thread will handle.  This is where you can merge your final results together.  This may require synchronization, but now, instead of synchronizing once per element (potentially millions of times), you’ll only have to synchronize once per thread, which is an ideal situation. Now that I’ve explained how this works, lets look at the code: // Safe, and fast! double min = double.MaxValue; // Make a "lock" object object syncObject = new object(); Parallel.ForEach( collection, // First, we provide a local state initialization delegate. () => double.MaxValue, // Next, we supply the body, which takes the original item, loop state, // and local state, and returns a new local state (item, loopState, localState) => { double value = item.PerformComputation(); return System.Math.Min(localState, value); }, // Finally, we provide an Action<TLocal>, to "merge" results together localState => { // This requires locking, but it's only once per used thread lock(syncObj) min = System.Math.Min(min, localState); } ); Although this is a bit more complicated than the previous version, it is now both thread-safe, and has minimal locking.  This same approach can be used by Parallel.For, although now, it’s Parallel.For<TLocal>.  When working with Parallel.For<TLocal>, you use the same triplet of delegates, with the same purpose and results. Also, many times, you can completely avoid locking by using a method of the Interlocked class to perform the final aggregation in an atomic operation.  The MSDN example demonstrating this same technique using Parallel.For uses the Interlocked class instead of a lock, since they are doing a sum operation on a long variable, which is possible via Interlocked.Add. By taking advantage of local state, we can use the Parallel class methods to parallelize algorithms such as aggregation, which, at first, may seem like poor candidates for parallelization.  Doing so requires careful consideration, and often requires a slight redesign of the algorithm, but the performance gains can be significant if handled in a way to avoid excessive synchronization.

    Read the article

  • .NET Backgroundworker - Is there no way to let exceptions pass back normally to main thread?

    - by Greg
    Hi, QUESTION: Re use of .NET Backgroundworker, is there not a way to let exceptions pass back normally to main thread? BACKGROUND: Currently in my WinForms application I have generic exception handle that goes along the lines of, if (a) a custom app exception then present to user, but don't exit program, and (b) if other exception then present and then exit application The above is nice as I can just throw the appropriate exception anywhere in the application and the presentation/handling is handled generically

    Read the article

  • Dynamic changes to thread stack size in Solaris 9 ?

    - by Satya
    Hello, I am looking for a configurable / tunable on Solaris 9 through which I can change the default thread stack size without recompiling the code to use "pthread_attr_setstacksize" For example on HPUX 11.11 / 11.23 the environment variable "PTHREAD_DEFAULT_STACK_SIZE" can be exported (available via HPUX patches PHCO_38307 / PHCO_38955 ) - Is there a equivalent Solaris 9 way to achieve the same ? Thanks! Satya

    Read the article

  • Fulltext search for django : Mysql not so bad ? (vs sphinx, xapian)

    - by Eric
    I am studying fulltext search engines for django. It must be simple to install, fast indexing, fast index update, not blocking while indexing, fast search. After reading many web pages, I put in short list : Mysql MYISAM fulltext, djapian/python-xapian, and django-sphinx I did not choose lucene because it seems complex, nor haystack as it has less features than djapian/django-sphinx (like fields weighting). Then I made some benchmarks, to do so, I collected many free books on the net to generate a database table with 1 485 000 records (id,title,body), each record is about 600 bytes long. From the database, I also generated a list of 100 000 existing words and shuffled them to create a search list. For the tests, I made 2 runs on my laptop (4Go RAM, Dual core 2.0Ghz): the first one, just after a server reboot to clear all caches, the second is done juste after in order to test how good are cached results. Here are the "home made" benchmark results : 1485000 records with Title (150 bytes) and body (450 bytes) Mysql 5.0.75/Ubuntu 9.04 Fulltext : ========================================================================== Full indexing : 7m14.146s 1 thread, 1000 searchs with single word randomly taken from database : First run : 0:01:11.553524 next run : 0:00:00.168508 Mysql 5.5.4 m3/Ubuntu 9.04 Fulltext : ========================================================================== Full indexing : 6m08.154s 1 thread, 1000 searchs with single word randomly taken from database : First run : 0:01:11.553524 next run : 0:00:00.168508 1 thread, 100000 searchs with single word randomly taken from database : First run : 9m09s next run : 5m38s 1 thread, 10000 random strings (random strings should not be found in database) : just after the 100000 search test : 0:00:15.007353 1 thread, boolean search : 1000 x (+word1 +word2) First run : 0:00:21.205404 next run : 0:00:00.145098 Djapian Fulltext : ========================================================================== Full indexing : 84m7.601s 1 thread, 1000 searchs with single word randomly taken from database with prefetch : First run : 0:02:28.085680 next run : 0:00:14.300236 python-xapian Fulltext : ========================================================================== 1 thread, 1000 searchs with single word randomly taken from database : First run : 0:01:26.402084 next run : 0:00:00.695092 django-sphinx Fulltext : ========================================================================== Full indexing : 1m25.957s 1 thread, 1000 searchs with single word randomly taken from database : First run : 0:01:30.073001 next run : 0:00:05.203294 1 thread, 100000 searchs with single word randomly taken from database : First run : 12m48s next run : 9m45s 1 thread, 10000 random strings (random strings should not be found in database) : just after the 100000 search test : 0:00:23.535319 1 thread, boolean search : 1000 x (word1 word2) First run : 0:00:20.856486 next run : 0:00:03.005416 As you can see, Mysql is not so bad at all for fulltext search. In addition, its query cache is very efficient. Mysql seems to me a good choice as there is nothing to install (I need just to write a small script to synchronize an Innodb production table to a MyISAM search table) and as I do not really need advanced search feature like stemming etc... Here is the question : What do you think about Mysql fulltext search engine vs sphinx and xapian ?

    Read the article

  • Unexpected behavior of IntentService

    - by kknight
    I used IntentService in my code instead of Service because IntentService creates a thread for me in onHandleIntent(Intent intent), so I don't have to create a Thead myself in the code of my service. I expected that two intents to the same IntentSerivce will execute in parallel because a thread is generated in IntentService for each invent. But my code turned out that the two intents executed in sequential way. This is my IntentService code: public class UpdateService extends IntentService { public static final String TAG = "HelloTestIntentService"; public UpdateService() { super("News UpdateService"); } protected void onHandleIntent(Intent intent) { String userAction = intent .getStringExtra("userAction"); Log.v(TAG, "" + new Date() + ", In onHandleIntent for userAction = " + userAction + ", thread id = " + Thread.currentThread().getId()); if ("1".equals(userAction)) { try { Thread.sleep(20 * 1000); } catch (InterruptedException e) { Log.e(TAG, "error", e); } Log.v(TAG, "" + new Date() + ", This thread is waked up."); } } } And the code call the service is below: public class HelloTest extends Activity { //@Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); Intent selectIntent = new Intent(this, UpdateService.class); selectIntent.putExtra("userAction", "1"); this.startService(selectIntent); selectIntent = new Intent(this, UpdateService.class); selectIntent.putExtra("userAction", "2"); this.startService(selectIntent); } } I saw this log message in the log: V/HelloTestIntentService( 848): Wed May 05 14:59:37 PDT 2010, In onHandleIntent for userAction = 1, thread id = 8 D/dalvikvm( 609): GC freed 941 objects / 55672 bytes in 99ms V/HelloTestIntentService( 848): Wed May 05 15:00:00 PDT 2010, This thread is waked up. V/HelloTestIntentService( 848): Wed May 05 15:00:00 PDT 2010, In onHandleIntent for userAction = 2, thread id = 8 I/ActivityManager( 568): Stopping service: com.example.android/.UpdateService The log shows that the second intent waited the first intent to finish and they are in the same thread. It there anything I misunderstood of IntentService. To make two service intents execute in parallel, do I have to replace IntentService with service and start a thread myself in the service code? Thanks.

    Read the article

  • Is it allowed to load Swing classes in non-EDT thread?

    - by ddimitrov
    After the introduction of Java Memory Model, the Swing guidelines were changed to state that any Swing components need to be instantiated on the EDT in order to avoid non-published instance state. What I could not find anywhere is whether the classloading is also mandated to be on the EDT or can we pre-load key Swing classes in a background thread? Is there any official statement from Sun/Oracle on this? Are there any classes that are known to hold non-threadsafe static state, hence need to be loaded on EDT?

    Read the article

  • Call HttpWebRequest in another thread as UI with Task class - avoid to dispose object created in Task scope

    - by John
    I would like call HttpWebRequest on another thread as UI, because I must make 200 request or server and downloaded image. My scenation is that I make a request on server, create image and return image. This I make in another thread. I use Task class, but it call automaticaly Dispose method on all object created in task scope. So I return null object from this method. public BitmapImage CreateAvatar(Uri imageUri, int sex) { if (imageUri == null) return CreateDefaultAvatar(sex); BitmapImage image = null; new Task(() => { var request = WebRequest.Create(imageUri); var response = request.GetResponse(); using (var stream = response.GetResponseStream()) { Byte[] buffer = new Byte[response.ContentLength]; int offset = 0, actuallyRead = 0; do { actuallyRead = stream.Read(buffer, offset, buffer.Length - offset); offset += actuallyRead; } while (actuallyRead > 0); image = new BitmapImage { CreateOptions = BitmapCreateOptions.None, CacheOption = BitmapCacheOption.OnLoad }; image.BeginInit(); image.StreamSource = new MemoryStream(buffer); image.EndInit(); image.Freeze(); } }).Start(); return image; } How avoid it? Thank Mr. Jon Skeet try this: private Stream GetImageStream(Uri imageUri) { Byte[] buffer = null; //new Task(() => //{ var request = WebRequest.Create(imageUri); var response = request.GetResponse(); using (var stream = response.GetResponseStream()) { buffer= new Byte[response.ContentLength]; int offset = 0, actuallyRead = 0; do { actuallyRead = stream.Read(buffer, offset, buffer.Length - offset); offset += actuallyRead; } while (actuallyRead > 0); } //}).Start(); return new MemoryStream(buffer); } It return object which is null a than try this: private Stream GetImageStream(Uri imageUri) { Byte[] buffer = null; new Task(() => { var request = WebRequest.Create(imageUri); var response = request.GetResponse(); using (var stream = response.GetResponseStream()) { buffer= new Byte[response.ContentLength]; int offset = 0, actuallyRead = 0; do { actuallyRead = stream.Read(buffer, offset, buffer.Length - offset); offset += actuallyRead; } while (actuallyRead > 0); } }).Start(); return new MemoryStream(buffer); } Method above return null

    Read the article

  • Exception in thread "main" java.lang.OutOfMemoryError, How to find and fix??

    - by or.nomore
    hey, I'm trying to programming a crossword creator. using a given dictionary txt file and a given pattern txt file. The basic idea is using DFS algorithm. the problem begin when the dictionary file is v-e-r-y big (about 50000 words). then i recive the : Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded i know that there is a part in my program that waists memory, but i don't know where it is, how to find it and how to fix it

    Read the article

  • Is it ok to perform DB operation on UI thread?

    - by user648462
    I am using a database to persist the state of a search form. I am using the onPause method to persist the data and the onResume method to restore it. My opinion is that restoring and persisting state should be a blocking operation so I plan to perform the database operations on the UI thread. I know this is generally discouraged but the operations should be quick and I think if they were done asynchronously they could lead to inconsistent UI behaviour. Any advice

    Read the article

  • how to know when a work in a thread is complete?

    - by seinkraft
    I need to create multiple threads when a button is clicked and i've done that with this: Dim myThread As New Threading.Thread(AddressOf getFile) myThread.IsBackground = True myThread.Start() but i need to update a picture box with the downloaded file, buy if i set an event in the function getFile and raise it to notify that the files was downloaded and then update the picturebox.

    Read the article

  • How long does it take each thread timeslice in Windows XP ?

    - by IHawk
    I am trying to find out how long does it take each thread timeslice (quantum) in Windows but the only information that I found out is about the clock ticks being from 15 to 20ms or 20-30ms. How can I find this information ? I think it may vary from OS to OS, but I am not certain. I appreciate any suggestion on this subject. Thank you.

    Read the article

< Previous Page | 54 55 56 57 58 59 60 61 62 63 64 65  | Next Page >