* [ECOS] Lightweight C++ multithreaded exceptions @ 2005-05-23 9:13 Øyvind Harboe 2005-05-23 12:52 ` Jerome Souquieres 0 siblings, 1 reply; 6+ messages in thread From: Øyvind Harboe @ 2005-05-23 9:13 UTC (permalink / raw) To: ecos-discuss One approach to supporting multithreaded exceptions that seem to work quite well in my experience is to use the single threaded GCC toolchain, but to make the the global variable in C++ exceptions, fc_static, per thread. By 'per thread' I mean that just like a generic CPU register, this global resource is part of the thread state. The easiest way of doing this that came to mind, was to add code to the eCos thread switching to save/restore the global variable on each thread switch. This requires reusing a field in the thread class or adding a new one. It was also suggested to make this support configureable via CDL as it adds a *very* slight overhead to thread switching. http://sources.redhat.com/ml/ecos-patches/2003-11/msg00047.html However, it requires a patch to GCC to make fc_static visible (it is currently declared static), which requires either get/set fn's or changing the name to avoid polluting the global namespace, e.g. _fc_static should do. Advantages: - very easy to do. 2 lines of code, 30 lines of fluff(#if'defs', etc.) 50 lines of documentation :-) - GCC patch is simply changing: static void *fc_static; => void *_fc_static; - no need to distinguish between single threaded or multithreaded toolchains - no need for multilib - very efficient implementation - no need for pthreads - trivial change to eCos - should work for all forseeable future Disadvantages: - requires a patch to GCC. -- Øyvind Harboe http://www.zylin.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] Lightweight C++ multithreaded exceptions 2005-05-23 9:13 [ECOS] Lightweight C++ multithreaded exceptions Øyvind Harboe @ 2005-05-23 12:52 ` Jerome Souquieres 2005-05-23 13:25 ` Øyvind Harboe 0 siblings, 1 reply; 6+ messages in thread From: Jerome Souquieres @ 2005-05-23 12:52 UTC (permalink / raw) To: Øyvind Harboe; +Cc: ecos-discuss Ãyvind Harboe wrote: >One approach to supporting multithreaded exceptions that seem to work >quite well in my experience is to use the single threaded GCC toolchain, >but to make the the global variable in C++ exceptions, fc_static, per >thread. > That's interesting. However, from what I understand, this approach only solves the multithreaded exceptions problem. This does nothing to ensure that the standard C++ library (including STL) is thead safe. Am I right ? -- Jerome Souquieres -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] Lightweight C++ multithreaded exceptions 2005-05-23 12:52 ` Jerome Souquieres @ 2005-05-23 13:25 ` Øyvind Harboe 2005-05-24 8:48 ` Jonathan Larmour 0 siblings, 1 reply; 6+ messages in thread From: Øyvind Harboe @ 2005-05-23 13:25 UTC (permalink / raw) To: Jerome Souquieres; +Cc: ecos-discuss On Mon, 2005-05-23 at 11:52 +0200, Jerome Souquieres wrote: > > That's interesting. However, from what I understand, this approach > only solves the multithreaded exceptions problem. This does nothing to > ensure that the standard C++ library (including STL) is thead safe. Am > I right ? I know there are some atomicity issues, but is that already handled in a CPU architecture specific but os-independent fashion by default in libstdc++? Does anyone know of a definitive list of issues w.r.t. libstdc++ & multithreading? I guess the fact that eCosCentric is destined to contribute their libstdc++ support saps my initiative for contributing patches in this area. Even more so, because I have a solution for my needs. -- Øyvind Harboe http://www.zylin.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] Lightweight C++ multithreaded exceptions 2005-05-23 13:25 ` Øyvind Harboe @ 2005-05-24 8:48 ` Jonathan Larmour 2005-05-24 9:01 ` Øyvind Harboe 2005-05-24 9:13 ` Paul D. DeRocco 0 siblings, 2 replies; 6+ messages in thread From: Jonathan Larmour @ 2005-05-24 8:48 UTC (permalink / raw) To: Øyvind Harboe; +Cc: Jerome Souquieres, ecos-discuss Ãyvind Harboe wrote: > On Mon, 2005-05-23 at 11:52 +0200, Jerome Souquieres wrote: > >> That's interesting. However, from what I understand, this approach >>only solves the multithreaded exceptions problem. This does nothing to >>ensure that the standard C++ library (including STL) is thead safe. Am >>I right ? > > > I know there are some atomicity issues, but is that already handled in a > CPU architecture specific but os-independent fashion by default in > libstdc++? libstdc++ has atomicity primitives for some CPUs, including x86, m68k, mips, powerpc and SPARC. Notably it doesn't include ARM, probably because at least on some ARM architecture versions it isn't possible. I don't know for definite about recent ARM architecture versions. But even that little atomicity support is only used in a handful of places, and on unsupported architectures it falls back to mutexes if available. However the key issue is that STL primarily uses OS mutexes if available, and also needs "once" variables. Without those, it is not thread-safe. > Does anyone know of a definitive list of issues w.r.t. libstdc++ & > multithreading? There is support for multithreading, but you have to do it its way. It's possible to hack it of course, but to do it the right way takes more effort. Certainly I had to make other changes to eCos (and the tools) to properly pass the libstdc++ testsuite. As you may have seen, there's a lot of tests there! It's probably inappropriate for me to comment on your suggested changes to kernel rescheduling to support the fc_static munging, but personally I don't believe kernel modifications are the right way. I know, I know, sitting here with it all working, I would say that wouldn't I :-). > I guess the fact that eCosCentric is destined to contribute their > libstdc++ support saps my initiative for contributing patches in this > area. While that is ultimately true, as I indicated before, it will not be in the near future. Anyone who hopes to hang on a bit in their project for it to be released publically is likely to be disappointed. > Even more so, because I have a solution for my needs. Your patches and instructions will certainly work in some situations. Some of it was using the code I included for our own C++ support anyway but did release :-), e.g. CYGPKG_LIBC_I18N_NEWLIB_CTYPE. But there are definitely a lot of gotchas once you introduce variation, including when you change to different architectures or try to use the libstdc++ library itself. Jifl -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] Lightweight C++ multithreaded exceptions 2005-05-24 8:48 ` Jonathan Larmour @ 2005-05-24 9:01 ` Øyvind Harboe 2005-05-24 9:13 ` Paul D. DeRocco 1 sibling, 0 replies; 6+ messages in thread From: Øyvind Harboe @ 2005-05-24 9:01 UTC (permalink / raw) To: Jonathan Larmour; +Cc: ecos-discuss > Your patches and instructions will certainly work in some situations. Some > of it was using the code I included for our own C++ support anyway but did > release :-), e.g. CYGPKG_LIBC_I18N_NEWLIB_CTYPE. But there are definitely > a lot of gotchas once you introduce variation, including when you change > to different architectures or try to use the libstdc++ library itself. I haven't taken my stuff through the libstdc++ testsuite. Mainly because there is very little point. It does what I need and eCosCentric is destined to release libstdc++ before these issues affect me. Or possibly things will linger long enough that I make one more pass over the libstdc++ stuff. No point in spending time until I know whether it is necessary :-) I've counted at least three projects that went from eCos to MMU-less Linux variants when they tried to get STL to work(all had oodles of RAM, which gives eCos less of an edge anyway) and I know there are at least a handful of people using my hacked up stopgap solution. -- Øyvind Harboe http://www.zylin.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [ECOS] Lightweight C++ multithreaded exceptions 2005-05-24 8:48 ` Jonathan Larmour 2005-05-24 9:01 ` Øyvind Harboe @ 2005-05-24 9:13 ` Paul D. DeRocco 1 sibling, 0 replies; 6+ messages in thread From: Paul D. DeRocco @ 2005-05-24 9:13 UTC (permalink / raw) To: eCos Discuss > From: Jonathan Larmour > > libstdc++ has atomicity primitives for some CPUs, including x86, m68k, > mips, powerpc and SPARC. Notably it doesn't include ARM, probably because > at least on some ARM architecture versions it isn't possible. I > don't know > for definite about recent ARM architecture versions. ARM7 and later have a swap byte or word, which is locked. -- Ciao, Paul D. DeRocco Paul mailto:pderocco@ix.netcom.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-05-23 19:26 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-05-23 9:13 [ECOS] Lightweight C++ multithreaded exceptions Øyvind Harboe 2005-05-23 12:52 ` Jerome Souquieres 2005-05-23 13:25 ` Øyvind Harboe 2005-05-24 8:48 ` Jonathan Larmour 2005-05-24 9:01 ` Øyvind Harboe 2005-05-24 9:13 ` Paul D. DeRocco
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).