Re: [PATCH v4] cpukit/librcxx: Add a C++ thread interface with attributes
On 3/10/20 10:21 pm, Joel Sherrill wrote:
> Will this show up in documentation somewhere?
Yes this is what I am planing. I was thinking of adding a Languages section to
the User manual and this would be part of the C++ section. We would need C and
Ada added.
> It does seem like we should say something about C++ threads and this.
Yes I agree.
> What about C11 threads?
That is C? This is about c++17 support.
> Test doesn't appear to cover much.
It tests:
- The standard C++ thread equivalent interface works:
thread_default = rtems::thread::thread(&test_thread::body, this,
"default", 1, 'D');
This checks the right constructor is selected. This thread should have the same
thread attributes and the standard library call.
- Inherit the current thread attributes with this single line:
rtems::thread::attributes attr;
- Modify the attributes:
attr.set_name("RTHREAD");
attr.set_priority(5);
attr.set_stack_size(32 * 1024);
- Create a thread with these new attributes:
thread_attr = rtems::thread::thread(attr, &test_thread::body, this,
"attr", 2, 'R');
Th test makes sure the hidden complexity needed to handle the variable template
arguments, move those to a new thread context and then have them made available
to thread body all work.
- Some more of the attributes could be tested.
> More interspersed
>
Great, comments with them. Thanks for the review.
Chris
>
> On Sat, Oct 3, 2020, 1:23 AM mailto:chr...@rtems.org>>
> wrote:
>
> From: Chris Johns mailto:chr...@rtems.org>>
>
> ---
> cpukit/include/rtems/c++/error | 65 +++
> cpukit/include/rtems/c++/thread | 469 ++
> cpukit/librtemscxx/error.cc | 76
> cpukit/librtemscxx/thread.cc | 416 +++
> spec/build/cpukit/grp.yml | 2 +
> spec/build/cpukit/librtemscxx.yml | 21 +
> spec/build/testsuites/libtests/grp.yml | 2 +
> spec/build/testsuites/libtests/rcxx01.yml | 22 +
> testsuites/libtests/rcxx01/init.c | 69
> testsuites/libtests/rcxx01/rcxx01.doc | 16 +
> testsuites/libtests/rcxx01/rcxx01.scn | 13 +
> testsuites/libtests/rcxx01/thread.cc | 90 +
> 12 files changed, 1261 insertions(+)
> create mode 100644 cpukit/include/rtems/c++/error
> create mode 100644 cpukit/include/rtems/c++/thread
> create mode 100644 cpukit/librtemscxx/error.cc
> create mode 100644 cpukit/librtemscxx/thread.cc
> create mode 100644 spec/build/cpukit/librtemscxx.yml
> create mode 100644 spec/build/testsuites/libtests/rcxx01.yml
> create mode 100644 testsuites/libtests/rcxx01/init.c
> create mode 100644 testsuites/libtests/rcxx01/rcxx01.doc
> create mode 100644 testsuites/libtests/rcxx01/rcxx01.scn
> create mode 100644 testsuites/libtests/rcxx01/thread.cc
>
> diff --git a/cpukit/include/rtems/c++/error
> b/cpukit/include/rtems/c++/error
> new file mode 100644
> index 00..8b9d875e0f
> --- /dev/null
> +++ b/cpukit/include/rtems/c++/error
> @@ -0,0 +1,65 @@
> +/* -*- C++ -*-
> + * SPDX-License-Identifier: BSD-2-Clause
> + *
> + * Copyright (C) 2020 Chris Johns (http://contemporary.software)
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in the
> + * documentation and/or other materials provided with the
> distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
> BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
> IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
> OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +/**
> + * @file
> + *
> + * @ingroup RTEMSC++
> + *
> + * RTEMS Error exception.
> + */
>
Re: Interest in Virtual RTEMS Workshop
Hello, Joel, I am currently organizing a virtual meeting for the EPICS community: https://indico.fhi-berlin.mpg.de/e/epics2020 This takes place in 2 weeks. If this works well, I would be happy to offer our platform (and our experience) for an RTEMS workshop. But the contributions would have to come from the RTEMS community ;-) Viele Grüße Heinz > On 2. Oct 2020, at 22:02, Joel Sherrill wrote: > > Hi > > In the past, we have internally discussed an RTEMS Workshop but always got > hung up on the basic logistics. There had to be a host site which usually > means cost. Although OAR now has access to a facility that could host about > 40-50. Travel required to all be in a central location would be burdensome > based on time and cost. Remember the core developers are spread across three > continents. > > The pandemic has made it clear that virtual meetings, conferences, birthday > parties, etc. are possible. Based on ideas from other open source projects, I > am curious if there would be interest in having a virtual workshop. > > One thought is that given the time zones, it might be nice to do it as a TBD > number of 2-3 hour sessions which vary in time across 2-3 days. That should > let different people participate. One open source project did a 24 hour event > which spanned the world. I do not want to do that. :) > > I think recording the presentations beforehand and making them available > afterwards would be ideal. I have seen formal setups where questions are > restricted to the end of the presentation but like the idea of the presenter > able to chat while their presentation is going. > > In my perfect world, most presentations would be from people using RTEMS, > although I expect core developer presentations would add depth to what they > are working on and the goals. > > Is there interest? Would you be willing to present? participate? Advice? > > Thanks. > > --joel > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel smime.p7s Description: S/MIME cryptographic signature ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Interest in Virtual RTEMS Workshop
On Sun, Oct 4, 2020, 12:49 PM Heinz Junkes wrote: > Hello, Joel, > I am currently organizing a virtual meeting for the EPICS community: > https://indico.fhi-berlin.mpg.de/e/epics2020 > > This takes place in 2 weeks. If this works well, I would be happy to offer > our platform (and our experience) for an RTEMS workshop. > But the contributions would have to come from the RTEMS community ;-) > Thanks! Google meet is likely ok. OAR's WebEx account can host up to 100 participants. Zoom may even be an option. I am kind of hoping to have presentations from the EPICS and CFS communities. Maybe a GSoC project session. And some from core developers on what they are doing. So don't think we don't want to hear about your work even if it is a repeat from the EPICS workshop. :) Viele Grüße > Heinz > > > On 2. Oct 2020, at 22:02, Joel Sherrill wrote: > > > > Hi > > > > In the past, we have internally discussed an RTEMS Workshop but always > got hung up on the basic logistics. There had to be a host site which > usually means cost. Although OAR now has access to a facility that could > host about 40-50. Travel required to all be in a central location would be > burdensome based on time and cost. Remember the core developers are spread > across three continents. > > > > The pandemic has made it clear that virtual meetings, conferences, > birthday parties, etc. are possible. Based on ideas from other open source > projects, I am curious if there would be interest in having a virtual > workshop. > > > > One thought is that given the time zones, it might be nice to do it as a > TBD number of 2-3 hour sessions which vary in time across 2-3 days. That > should let different people participate. One open source project did a 24 > hour event which spanned the world. I do not want to do that. :) > > > > I think recording the presentations beforehand and making them available > afterwards would be ideal. I have seen formal setups where questions are > restricted to the end of the presentation but like the idea of the > presenter able to chat while their presentation is going. > > > > In my perfect world, most presentations would be from people using > RTEMS, although I expect core developer presentations would add depth to > what they are working on and the goals. > > > > Is there interest? Would you be willing to present? participate? Advice? > > > > Thanks. > > > > --joel > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Interest in Virtual RTEMS Workshop
We are using BlueJeans Events for our workshop/meeting. FHI, Heinz Junkes > On 4. Oct 2020, at 21:15, Joel Sherrill wrote: > > > > >> On Sun, Oct 4, 2020, 12:49 PM Heinz Junkes wrote: >> Hello, Joel, >> I am currently organizing a virtual meeting for the EPICS community: >> https://indico.fhi-berlin.mpg.de/e/epics2020 >> >> This takes place in 2 weeks. If this works well, I would be happy to offer >> our platform (and our experience) for an RTEMS workshop. >> But the contributions would have to come from the RTEMS community ;-) > > > Thanks! Google meet is likely ok. OAR's WebEx account can host up to 100 > participants. Zoom may even be an option. > > > I am kind of hoping to have presentations from the EPICS and CFS communities. > Maybe a GSoC project session. And some from core developers on what they are > doing. So don't think we don't want to hear about your work even if it is a > repeat from the EPICS workshop. :) > > >> Viele Grüße >> Heinz >> >> > On 2. Oct 2020, at 22:02, Joel Sherrill wrote: >> > >> > Hi >> > >> > In the past, we have internally discussed an RTEMS Workshop but always got >> > hung up on the basic logistics. There had to be a host site which usually >> > means cost. Although OAR now has access to a facility that could host >> > about 40-50. Travel required to all be in a central location would be >> > burdensome based on time and cost. Remember the core developers are spread >> > across three continents. >> > >> > The pandemic has made it clear that virtual meetings, conferences, >> > birthday parties, etc. are possible. Based on ideas from other open source >> > projects, I am curious if there would be interest in having a virtual >> > workshop. >> > >> > One thought is that given the time zones, it might be nice to do it as a >> > TBD number of 2-3 hour sessions which vary in time across 2-3 days. That >> > should let different people participate. One open source project did a 24 >> > hour event which spanned the world. I do not want to do that. :) >> > >> > I think recording the presentations beforehand and making them available >> > afterwards would be ideal. I have seen formal setups where questions are >> > restricted to the end of the presentation but like the idea of the >> > presenter able to chat while their presentation is going. >> > >> > In my perfect world, most presentations would be from people using RTEMS, >> > although I expect core developer presentations would add depth to what >> > they are working on and the goals. >> > >> > Is there interest? Would you be willing to present? participate? Advice? >> > >> > Thanks. >> > >> > --joel >> > ___ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel >> smime.p7s Description: S/MIME cryptographic signature ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RTEMS 5.1 pc686 BSP malloc_info problem?
Hi, I have a problem in RTEMS 5.1 where the pc686 running on QEMU seems to block or spin when trying to acquire a lock for the malloc_info call. The CPU utilization goes up to 100 (on the QEMU host) leading me to think the calling task is spinning waiting on the lock. Tasks with lower priority than the calling task stop running as well. I also get this problem when running the "malloc info" shell command. I don't see this problem with the leon3 BSP built from the same source tree and executed on QEMU. Is there an SMP related initialization or perhaps QEMU option I might be missing? I can run the same code without problems on the RTEMS 4.11 release (same QEMU binary and QEMU options) Thanks, Alan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v3 2/2] Add AArch64 documentation
On 04/10/2020 06:23, Kinsey Moore wrote: +.. Copyright (C) 2020 Kinsey Moore, On-Line Applications Research Corporation (OAR) I think each copyright holder should have its own line. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
