Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #955

Re: Using sigsetjmp/siglongjmp from multithreaded application

Show all headers | View raw

Hi,

On 20.07.2012 23:42, Michael Podolsky wrote:
> I am writing a stack tracing code and to make this code safe I want to protect myself from a SIGSEGV.
>
> So I chose to process SIGSEGV and jump from a signal handler to a position set by sigsetjmp. Then, to my disappointment I found that there is no straightforward solution to associate a sigjmp_buf buffer with a particular thread.
>
> I can't use standard thread local storage or implement it by myself with mutexes because these functions should not be called from a signal hanlder.

Depending on your platform, it might be not that complicated.

First of all, some platforms always use rather small thread IDs. In this 
case a reasonably large static array would do well. The array index is 
the thread ID. While this is not the best memory layout with respect to 
multi core cache performance, as long as write access comes not that 
often you are fine. OK, if you want to serve any 16 bit thread ID it can 
take in the order of 10 MB. But it is only virtual address space unless 
you access it.

Secondly you could use lock free data structures. A common approach is 
to have some kind of dictionary which is atomically replaced by a new 
one with CompareAndSwap. Once a dictionary is "published" it is 
immutable. However, its values are thread-local and therefore might be 
accessed without a mutex. The drawback is that the life-time management 
of the dictionaries is not that easy since you need strong thread safety.
If you need not to serve a large number of threads a single, lock-free 
linked list may be sufficient too. The only drawback is the O(n) access 
to the thread local storage.

Last but not least you could simply use a spin-lock. As long as your 
critical sections are quite small, you will not run into significant 
trouble.


> And, I don't want to run stack tracing code under a mutex as the performance of application may degrade -- otherwise I could solve my task by having one thread only at risk of SIGSEGV and one sigjmp_buf per whole application.

As far as I can see, the TLS is only accessed occasionally when you set 
the jump target or when SIGSEGV occurs. So I do not see where the 
performance counts much.


> So, going back, is there a robust way in linux to write a multithread application in which some critical parts of code are SIGSEGV-tolerant?

Of course, see above. It depends on how much effort you like to spent.


Marcel

Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Using sigsetjmp/siglongjmp from multithreaded application Michael Podolsky <michael.podolsky.69@gmail.com> - 2012-07-20 14:42 -0700
  Re: Using sigsetjmp/siglongjmp from multithreaded application "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2012-07-21 03:32 +0200
    Re: Using sigsetjmp/siglongjmp from multithreaded application "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2012-07-21 04:05 +0200
      Re: Using sigsetjmp/siglongjmp from multithreaded application Michael Podolsky <michael.podolsky.69@gmail.com> - 2012-07-24 10:22 -0700
        Re: Using sigsetjmp/siglongjmp from multithreaded application "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2012-07-25 03:28 +0200
  Re: Using sigsetjmp/siglongjmp from multithreaded application Marcel Müller <news.5.maazl@spamgourmet.com> - 2012-07-21 09:10 +0200
    Re: Using sigsetjmp/siglongjmp from multithreaded application Michael Podolsky <michael.podolsky.69@gmail.com> - 2012-07-24 10:34 -0700
      Re: Using sigsetjmp/siglongjmp from multithreaded application Marcel Müller <news.5.maazl@spamgourmet.com> - 2012-07-24 22:58 +0200
        Re: Using sigsetjmp/siglongjmp from multithreaded application Drazen Kacar <dave@fly.srk.fer.hr> - 2012-07-24 21:23 +0000
        Re: Using sigsetjmp/siglongjmp from multithreaded application Michael Podolsky <michael.podolsky.69@gmail.com> - 2012-07-24 15:48 -0700

csiph-web