Hi,
I added const modifiers and replaced NULL with nullptr, I still fail to see how BaseThread is a descendant of ThreadReference (which I made final). Could you point out where this slicing would occur?
Giovanni
C++ blocking API needs updating Topic is solved
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
- Spym
- Posts: 45
- Joined: Tue Oct 15, 2013 10:20 am
- Location: Tallinn, Estonia
- Has thanked: 2 times
- Been thanked: 3 times
- Contact:
Re: C++ blocking API needs updating
Sorry! I just looked at the code again and indeed, the problem is gone. Previously I was looking at an outdated file.
It's an unexpected solution but it works. It would make sense for the reference to be a base class of BaseThread, but it certainly isn't necessary.
It's an unexpected solution but it works. It would make sense for the reference to be a base class of BaseThread, but it certainly isn't necessary.
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: C++ blocking API needs updating
Some kind of object is needed for all those functions that return a pointer to threads, it is basically just an encapsulated pointer.
Giovanni
Giovanni
- Spym
- Posts: 45
- Joined: Tue Oct 15, 2013 10:20 am
- Location: Tallinn, Estonia
- Has thanked: 2 times
- Been thanked: 3 times
- Contact:
Re: C++ blocking API needs updating
Thanks. It also occurred to me that we're missing RAII helpers for mutexes and critical sections. I have them defined in my application, but there's no reason why they shouldn't be part of the OS. Consider the following code (copy-pasted from my application with minimal changes):
Would you be up to adding that to the wrapper?
Code: Select all
namespace impl_
{
class MutexLockerImpl
{
chibios_rt::Mutex& mutex_;
public:
MutexLockerImpl(chibios_rt::Mutex& m) : mutex_(m) { mutex_.lock(); }
~MutexLockerImpl() { mutex_.unlock(); }
};
class CriticalSectionLockerImpl
{
volatile const ::syssts_t st_ = chSysGetStatusAndLockX();
public:
~CriticalSectionLockerImpl() { chSysRestoreStatusX(st_); }
};
}
/**
* RAII mutex locker.
* Must be volatile in order to prevent the optimizer from throwing it away.
*/
using MutexLocker = volatile impl_::MutexLockerImpl;
/**
* RAII critical section locker.
* Must be volatile in order to prevent the optimizer from throwing it away.
*/
using CriticalSectionLocker = volatile impl_::CriticalSectionLockerImpl;
Would you be up to adding that to the wrapper?
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: C++ blocking API needs updating
I added a "Monitor" construct but there is no obvious way to implement Java-like synchronized methods, locking and unlocking the inner mutex must be done explicitly.
Several other refinements and documentation fixes.
I think it needs more work before making it "official".
Giovanni.
Several other refinements and documentation fixes.
I think it needs more work before making it "official".
Giovanni.
- Spym
- Posts: 45
- Joined: Tue Oct 15, 2013 10:20 am
- Location: Tallinn, Estonia
- Has thanked: 2 times
- Been thanked: 3 times
- Contact:
Re: C++ blocking API needs updating
RAII is a common pattern in C++. The code I posted is a complete solution that requires no further modifications, it's quite well tested as well.
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Who is online
Users browsing this forum: No registered users and 26 guests