search for: thread2

...1:[0-9]+]], kind: function-enter, tsc: {{[0-9]+}} } // TRACE: - { type: 0, func-id: [[FIDA]], function: {{.*fA.*}}, cpu: {{.*}}, thread: [[THREAD1]], kind: function-{{exit|tail-exit}}, tsc: {{[0-9]+}} } // TRACE-DAG: - { type: 0, func-id: [[FIDA]], function: {{.*fA.*}}, cpu: {{.*}}, thread: [[THREAD2:[0-9]+]], kind: function-enter, tsc: {{[0-9]+}} } // TRACE: - { type: 0, func-id: [[FIDA]], function: {{.*fA.*}}, cpu: {{.*}}, thread: [[THREAD2]], kind: function-{{exit|tail-exit}}, tsc: {{[0-9]+}} } // // Do the same as above for fC() // TRACE-DAG: - { type: 0, func-id: [[FIDC:[0-9]+]], f...

...hat the JITter doesn't like running in anything other than the primary fibre. For example, #include <stdio.h> #include "../../mcp/tools/mcp2/mcpapi.h" void thread1(void *udata) { int i; for(i=0; i<10; i++) { printf("--- thread1: Hello (%d)\n", i); } } void thread2(void *udata) { int i; for(i=0; i<10; i++) { printf("--- thread2 Hello (%d)\n", i); } } int main(int argc, char **argv) { printf("--- Running threads serially:\n"); thread1(0); thread2(0); printf("--- Running threads in parallel:\n"); mcp_begin_thread(th...

Check out http://nondot.org/sabre/LLVMNotes -Chris http://nondot.org/sabre http://llvm.org On Jul 27, 2007, at 12:00 PM, Sarah Thompson <thompson at email.arc.nasa.gov > wrote: > Hi folks, > > Assuming that I'm writing a pass and that for bizarre reasons I need > to > programmatically do the equivalent of a C/C++ sizeof on a Value (or a > Type, it doesn't

Hi folks, Assuming that I'm writing a pass and that for bizarre reasons I need to programmatically do the equivalent of a C/C++ sizeof on a Value (or a Type, it doesn't matter which really), yielding a result in bytes, what is the known-safe way to do this? I notice that doing something like struct thingy { ... some stuff ... }; ... printf("Size = %d",

...ry datebase, like this: Xapian::WritableDatabase db(Xapian::InMemory::open()); *But, if i use these in multithread program, i need create many datebases!!* Xapian::WritableDatabase db1(Xapian::InMemory::open()); //used in thread1 Xapian::WritableDatabase db2(Xapian::InMemory::open()); //used in thread2 because WritableDatabase object isn't thread-safe. And use lock is slowly. *So, is there some solutions that One database, many thread can use??* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xapian.org/pipermail/xapian-devel/attachments/2014...

...ink) assumes that a "read entry" will be followed by a "read return" probe. On a per-thread basis, I can see this happening, but if the application has multiple threads/readers/writers, isn''t it possible to get interleaved syscalls? For example, Thread1-> read entry Thread2 -> write entry Thread1 -> read return Thread2 -> write return If so, then shouldn''t the pfilestat script be using thread local variables for timing versus globabl variables? -- This message posted from opensolaris.org

I wouldn't report this if not for one coincidence (which is described below). I have too little facts, so this is more of a mystery problem tale than a real problem report. There are two systems: 1. old, slow, i386, UP, 7-STABLE 2. new, fast, amd64, MP, 6.3-RELEASE Systems are located at different physical locations. What is common between them: 1. they both have the same backup strategy

...gt;> __attribute__((noinline)) void foo() { v[0] = 42; } >> >> void *Thread1(void *) { >> for (int i = 0; i < 100000000; i++) >> foo(); >> return 0; >> } >> >> __attribute__((noinline)) void bar() { v[999] = 66; } >> >> void *Thread2(void *) { >> for (int i = 0; i < 100000000; i++) >> bar(); >> return 0; >> } >> >> int main() { >> static const int kNumThreads = 16; >> pthread_t t[kNumThreads]; >> pthread_create(&t[0], 0, Thread1, 0); >> pthread_create(...

...:vector<int> v(1000); > > __attribute__((noinline)) void foo() { v[0] = 42; } > > void *Thread1(void *) { > for (int i = 0; i < 100000000; i++) > foo(); > return 0; > } > > __attribute__((noinline)) void bar() { v[999] = 66; } > > void *Thread2(void *) { > for (int i = 0; i < 100000000; i++) > bar(); > return 0; > } > > int main() { > static const int kNumThreads = 16; > pthread_t t[kNumThreads]; > pthread_create(&t[0], 0, Thread1, 0); > pthread_create(&t[1], 0, Thread2, 0); &gt...

On Fri, Apr 18, 2014 at 12:13 AM, Dmitry Vyukov <dvyukov at google.com> wrote: > Hi, > > This is long thread, so I will combine several comments into single email. > > > >> - 8-bit per-thread counters, dumping into central counters on overflow. > >The overflow will happen very quickly with 8bit counter. > > Yes, but it reduces contention by 256x (a thread

...may_oom() and held oom_lock > mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it > will cause OOM lockup. Thus, do not wait for vb->balloon_lock mutex if > leak_balloon() is called from out_of_memory(). > > Thread1 Thread2 > fill_balloon() > takes a balloon_lock > balloon_page_enqueue() > alloc_page(GFP_HIGHUSER_MOVABLE) > direct reclaim (__GFP_FS context) takes a fs lock > waits for that fs lock alloc_page(GFP_NOFS) >...

...may_oom() and held oom_lock > mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it > will cause OOM lockup. Thus, do not wait for vb->balloon_lock mutex if > leak_balloon() is called from out_of_memory(). > > Thread1 Thread2 > fill_balloon() > takes a balloon_lock > balloon_page_enqueue() > alloc_page(GFP_HIGHUSER_MOVABLE) > direct reclaim (__GFP_FS context) takes a fs lock > waits for that fs lock alloc_page(GFP_NOFS) >...

...it reached __alloc_pages_may_oom() and held oom_lock mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it will cause OOM lockup. Thus, do not wait for vb->balloon_lock mutex if leak_balloon() is called from out_of_memory(). Thread1 Thread2 fill_balloon() takes a balloon_lock balloon_page_enqueue() alloc_page(GFP_HIGHUSER_MOVABLE) direct reclaim (__GFP_FS context) takes a fs lock waits for that fs lock alloc_page(GFP_NOFS)...

...it reached __alloc_pages_may_oom() and held oom_lock mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it will cause OOM lockup. Thus, do not wait for vb->balloon_lock mutex if leak_balloon() is called from out_of_memory(). Thread1 Thread2 fill_balloon() takes a balloon_lock balloon_page_enqueue() alloc_page(GFP_HIGHUSER_MOVABLE) direct reclaim (__GFP_FS context) takes a fs lock waits for that fs lock alloc_page(GFP_NOFS)...

I created a wiki at http://code.google.com/p/llvm-stack-switch/ Right now I just copied and formatted the document as-is... I'll go back over it with your comments in mind soon. One more question, which you can answer here or there: > Point 4 is a bit confusing. Normally, it's fine for a thread to share > some of its stack space with another thread, but your wording seems to >

...via virtballoon_oom_notify() via blocking_notifier_call_chain() callback via out_of_memory() when it reached __alloc_pages_may_oom() and held oom_lock mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it will cause OOM lockup. Thread1 Thread2 fill_balloon() takes a balloon_lock balloon_page_enqueue() alloc_page(GFP_HIGHUSER_MOVABLE) direct reclaim (__GFP_FS context) takes a fs lock waits for that fs lock alloc_page(GFP_NOFS)...

...via virtballoon_oom_notify() via blocking_notifier_call_chain() callback via out_of_memory() when it reached __alloc_pages_may_oom() and held oom_lock mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it will cause OOM lockup. Thread1 Thread2 fill_balloon() takes a balloon_lock balloon_page_enqueue() alloc_page(GFP_HIGHUSER_MOVABLE) direct reclaim (__GFP_FS context) takes a fs lock waits for that fs lock alloc_page(GFP_NOFS)...

...may_oom() and held oom_lock > mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it > will cause OOM lockup. Thus, do not wait for vb->balloon_lock mutex if > leak_balloon() is called from out_of_memory(). > > Thread1 Thread2 > fill_balloon() > takes a balloon_lock > balloon_page_enqueue() > alloc_page(GFP_HIGHUSER_MOVABLE) > direct reclaim (__GFP_FS context) takes a fs lock > waits for that fs lock alloc_page(GFP_NOFS) >...

...may_oom() and held oom_lock > mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it > will cause OOM lockup. Thus, do not wait for vb->balloon_lock mutex if > leak_balloon() is called from out_of_memory(). > > Thread1 Thread2 > fill_balloon() > takes a balloon_lock > balloon_page_enqueue() > alloc_page(GFP_HIGHUSER_MOVABLE) > direct reclaim (__GFP_FS context) takes a fs lock > waits for that fs lock alloc_page(GFP_NOFS) >...

...may_oom() and held oom_lock > mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it > will cause OOM lockup. Thus, do not wait for vb->balloon_lock mutex if > leak_balloon() is called from out_of_memory(). > > Thread1 Thread2 > fill_balloon() > takes a balloon_lock > balloon_page_enqueue() > alloc_page(GFP_HIGHUSER_MOVABLE) > direct reclaim (__GFP_FS context) takes a fs lock > waits for that fs lock alloc_page(GFP_NOFS) >...