synchronization

I'm trying to get a GM_xmlhttpRequest call to behave synchronously, but I can't get it to work like I expect: function myFunction (arg) { var a; GM_xmlhttpRequest ( { method: "GET", url: "http://example.com/sample/url", synchronous: true, onload: function (details) { a = details.responseText; } } ); return a; } b = myFunction (); alert (b); I never get anything back for b here; it's undefined. Is there some step that I'm missing here? I'm using v0.9.13 of Greasemonkey, and v9.0.1 of Firefox. Just stumbled upon this topic in Google. Synchronous GM_xmlhttpRequest RETURN the result instead of

I want to store data in a large array with _mm256_stream_si256() called in a loop. As I understood, a memory fence is then needed to make these changes visible to other threads. The description of _mm_sfence() says Perform a serializing operation on all store-to-memory instructions that were issued prior to this instruction. Guarantees that every store instruction that precedes, in program order, is globally visible before any store instruction which follows the fence in program order. But will my recent stores of the current thread be visible to subsequent load instructions too (in the other

What are the possible problems caused by adding elements to unsynchronized ArrayList 's object by multiple threads simultaneously? Tried to run some experiments with a static ArrayList with multiple threads but couldn't find much. Here i am expecting much of the side effects of not synchronizing an ArrayList or like Objects in a multithreaded environment. Any good example showing side effects would be appreciable. thanks. below is my little experiment which ran smoothly without any exception. I also wonder why it didn't throw any ConcurrentModificationException ? import java.util.ArrayList;

I have been reading Memory Barriers: A Hardware View For Software Hackers , a very popular article by Paul E. McKenney. One of the things the paper highlights is that, very weakly ordered processors like Alpha, can reorder dependent loads which seems to be a side effect of partitioned cache Snippet from the paper: 1 struct el *insert(long key, long data) 2 { 3 struct el *p; 4 p = kmalloc(sizeof(*p), GPF_ATOMIC); 5 spin_lock(&mutex); 6 p->next = head.next; 7 p->key = key; 8 p->data = data; 9 smp_wmb(); 10 head.next = p; 11 spin_unlock(&mutex); 12 } 13 14 struct el *search(long key) 15 { 16

In a nice article with some concurrency tips , an example was optimized to the following lines: double getBalance() { Account acct = verify(name, password); synchronized(acct) { return acct.balance; } } If I understand that correctly, the point of the synchronization is to ensure that the value of acct.balance that are read by this thread is current and that any pending writes to the fields of the object in acct.balance are also written to main memory. The example made me think a little: wouldn't it be more efficient to just declare acct.balance (i.e. the field balance of class Account) as

It is said that you should only call asynchronous-safe functions inside a signal handler. My question is, what constitutes asynchronous-safeness ? A function which is both reentrant and thread safe is asynchronous-safe I guess? Or No? Re-entrance and thread safety has a little or nothing to do with this. Side effects, state and interruption of those functions are facts that matter. asynchronous-safe function [GNU Pth] A function is asynchronous-safe, or asynchronous-signal safe, if it can be called safely and without side effects from within a signal handler context. That is, it must be able