Understanding semaphores with pthreads (code included) - locking

So in class, we learned about semaphores and stuff and our professor let us know that this code below would be handy to learn for our exam. Unfortunately our exam is on Friday, and whole list of excuses, i just need to be able to understand this code for the exam and for future cases. I understand that the mutex_t is a lock system and the cond_t is a condition system in which signals get passed through sema_P and sema_V (if the value is 0, race condition occurs and the thread is locked out by cond_wait until another thread increases the value and is unlocked by cond_signal), but why does a lock need to get passed around? Why is there a mutex_lock and mutex_unlock in both decrementer P() and incrementer V()? How does this work with the threads and the conditions (cont_t)?
typedef struct
{
pthread_mutex_t lock;
pthread_cond_t wait;
int value;
} sema;
void pthread_sema_init(sema *s, int count)
{
s->value = count;
pthread_cond_init(&(s->wait),NULL);
pthread_mutex_init(&(s->lock),NULL);
return;
}
void pthread_sema_P(sema *s)
{
pthread_mutex_lock(&(s->lock));
s->value--;
if(s->value < 0) {
pthread_cond_wait(&(s->wait),&(s->lock));
}
pthread_mutex_unlock(&(s->lock));
return;
}
void pthread_sema_V(sema *s)
{
pthread_mutex_lock(&(s->lock));
s->value++;
if(s->value <= 0) {
pthread_cond_signal(&(s->wait));
}
pthread_mutex_unlock(&(s->lock));
}

The mutex sema.lock is there to protect the shared variable sema.value, ensuring that only one thread accesses that value at a time. Both pthread_sema_P() and pthread_sema_V() must take the lock because they both access sema.value.
That implementation of sempahores is buggy, by the way - it doesn't handle spurious wakeups (a "spurious wakeup" is where pthread_cond_wait() wakes up despite not being signalled - this is allowed by the spec).
A more traditional implementation might be:
void pthread_sema_P(sema *s)
{
pthread_mutex_lock(&s->lock);
while (s->value < 1) {
pthread_cond_wait(&s->wait, &s->lock);
}
s->value--;
pthread_mutex_unlock(&s->lock);
}
void pthread_sema_V(sema *s)
{
pthread_mutex_lock(&s->lock);
s->value++;
pthread_cond_signal(&s->wait);
pthread_mutex_unlock(&s->lock);
}

Related

Need help to implement an interrupt controller simulator which handles the ISR

I am on the implementation of an interrupt controller simulator, which will take signals from other rest of the HW modules in simulation and run the ISR.
Below is the SystemC code roughly made to get the concept clear. In this case, we need ISR to be handled in a way that, even if the FW_main is stuck inside while(1) loop.
With the below implementation the context is inside FW_main loop only. Adding a wait in FW_main is not the one we want. We need the correct interrupt controller functionality. Any ideas to get rid of this problem?
SC_MODULE (processor)
{
sc_in < bool > interrupt;
void ISR(void)
{
cout << "i am in ISR\n";
}
void FW_main(void)
{
while(1)
{
cout << "i am in FW_main\n";
}
}
SC_CTOR (processor)
{
SC_METHOD(ISR);
sensitive << interrupt;
SC_THREAD(FW_main);
}
};
Unfortunately SystemC processes are cooperative, not preemptive. Even the SystemC kernel can't step in and suspend the FW_main method.
No processor system / FW truly gets stuck in a while loop this way. Any instruction set simulator must walk the time in steps on some sort of strobes or events, ideally clock edges.
Functional representation of a system you are trying to model would look something like follows.
SC_MODULE (processor)
{
sc_in < bool > clk;
sc_in < bool > interrupt;
void ISR(void)
{
cout << "i am in ISR\n";
}
void FW_main(void)
{
cout << "i am in FW_main\n";
}
SC_CTOR (processor)
{
SC_METHOD(ISR);
sensitive << interrupt;
SC_METHOD(FW_main);
sensitive << clk;
}
};
There are two problems in above code I suggested. First, you probably don't want an actual clock signal that needs toggling externally or any sense of time at all for that matter. Second, in a single core processor system, ISRs and FW_Main aren't really parallel in nature. A more realistic implementation of what you are trying to model would be as follows.
SC_MODULE(processor)
{
sc_in < bool > interrupt;
void ISR(void)
{
cout << "i am in ISR\n";
}
void FW_main(void)
{
if(interrupt.read())
{
ISR();
}
cout << "i am in FW_main\n";
next_trigger(SC_ZERO_TIME, interrupt);
}
SC_CTOR (processor)
{
SC_METHOD(FW_main);
}
};
The next_trigger(SC_ZERO_TIME, interrupt) statement makes the FW_main emulate while(1) while also being sensitive to interrupt input.

Asynchronous hiredis with libev and pthread, what am I doing wrong?

I am writing a GUI for a small monochromatic display and I want to update the data on the screen every second.
The data is stored in a redis database and I am trying to coordinate using pthread, libev, and asynchronous hiredis calls.
My plan is to have a thread that pulls new data from the database every second and store a local copy for quick access.
Another thread that updates the screen will access that data at will without having to wait for database access.
First question, is my approach correct?
Second question, why am I having trouble polling the database every second? I think I can switch to a synchronous method and get it to work but is that the right approach?
Here is the relevant code:
int main(int argc, char *argv[])
{
pthread_t dataThread;
pthread_t guiThread;
pthread_create(&dataThread, NULL, dataHandler, NULL);
pthread_create(&guiThread, NULL, guiHandler, NULL);
while (true)
{
sleep(10);
}
return 0;
}
In the following, if I move ev_loop(EV_DEFAULT_ 0); inside the while loop after the redisAsync commands my callback gets called for the first loop but never again. The way it sits, my callback never gets called.
void* dataHandler(void *ptr)
{
m_ctx = redisAsyncConnect("127.0.0.1", 6379);
if (m_ctx->err) {
printf("Redis async connection failed. Error: %s\n", m_ctx->errstr);
exit(-1);
}
redisLibevAttach(EV_DEFAULT_ m_ctx);
redisAsyncSetConnectCallback(m_ctx,connectCallback);
redisAsyncSetDisconnectCallback(m_ctx,disconnectCallback);
ev_loop(EV_DEFAULT_ 0);
while (true)
{
int result;
result = redisAsyncCommand(m_ctx, updateCallback, (char*)"data1", "HGET data1 data");
printf("result: %d\n", result);
result = redisAsyncCommand(m_ctx, updateCallback, (char*)"data2", "HGET data2 data");
printf("result: %d\n", result);
//ev_loop(EV_DEFAULT_ 0); <- this will work one time
}
redisAsyncDisconnect(m_ctx);
return 0;
}
void updateCallback(redisAsyncContext *c, void *r, void *privdata)
{
redisReply *reply = (redisReply*)r;
if (reply == NULL) return;
printf("%s: %s\n", (char*)privdata, reply->str);
}
void* guiHandler(void *ptr)
{
while (true)
{
// Update the GUI accordingly
sleep(1);
}
}
Firstly, I would recommend you to read the manual for libev before using it :
http://man7.org/linux/man-pages/man3/event.3.html
Now for your code,
ev_loop function will start an event loop that you only "feed" it with 2 HGET operations.
In order to add more operations you need to add attach events for the event loop but I'm not sure it will be the right approach for you case.
If the purpose of your thread is just to fetch the db every X seconds why are you using the async approach at all? IMO just use the hiredis sync API

How to force a libusb event so that libusb_handle_events() returns

Suppose I have a libusb program that just uses the hotplug API. You register a callback and then apparently have to call libusb_handle_events() in a loop which then calls your hotplug callback.
int LIBUSB_CALL hotplugCallback(libusb_context* ctx,
libusb_device* device,
libusb_hotplug_event event,
void* user_data)
{
cout << "Device plugged in or unplugged";
}
void main()
{
libusb_init(nullptr);
libusb_hotplug_register_callback(nullptr,
static_cast<libusb_hotplug_event>(LIBUSB_HOTPLUG_EVENT_DEVICE_ARRIVED | LIBUSB_HOTPLUG_EVENT_DEVICE_LEFT),
LIBUSB_HOTPLUG_NO_FLAGS,
LIBUSB_HOTPLUG_MATCH_ANY,
LIBUSB_HOTPLUG_MATCH_ANY,
LIBUSB_HOTPLUG_MATCH_ANY,
&hotplugCallback,
this,
&hotplugCallbackHandle);
for (;;)
{
if (libusb_handle_events_completed(nullptr, nullptr) != LIBUSB_SUCCESS)
return 1;
}
return 0;
}
The question is, without timeout hacks how can I exit this event loop cleanly? I can't find any functions that force libusb_handle_events() (or libusb_handle_events_completed()) to return. In theory they could just never return.
Sorry if this is late.
The question could have been phrased better but I'm assuming (from your comment updates) that your actual program resembles something a little closer to this:
int LIBUSB_CALL hotplugCallback(libusb_context *ctx,
libusb_device *device,
libusb_hotplug_event event,
void *user_data) {
cout << "Device plugged in or unplugged";
}
void SomeClass::someFunction() {
libusb_init(nullptr);
libusb_hotplug_register_callback(nullptr,
static_cast<libusb_hotplug_event>(LIBUSB_HOTPLUG_EVENT_DEVICE_ARRIVED | LIBUSB_HOTPLUG_EVENT_DEVICE_LEFT),
LIBUSB_HOTPLUG_NO_FLAGS,
LIBUSB_HOTPLUG_MATCH_ANY,
LIBUSB_HOTPLUG_MATCH_ANY,
LIBUSB_HOTPLUG_MATCH_ANY,
&hotplugCallback,
this,
&hotplugCallbackHandle);
this->thread = std::thread([this]() {
while (this->handlingEvents) {
int error = libusb_handle_events_completed(context, nullptr);
}
});
}
Let's say your object is being deallocated and, no matter what is happening on the USB bus, you don't care and you want to clean up your thread.
You negate this->handlingEvents and you call thread.join() and the thread hangs for 60 seconds and then execution resumes.
This is done because the default behavior of libusb_handle_events_completed calls libusb_handle_events_timeout_completed and passes in a 60 second timeout interval with plans to make it infinite.
The way you force libusb_handle_events_completed to return is you call libusb_hotplug_deregister_callback which wakes up libusb_handle_events(), causing the function to return.
There is more info about this behavior in the docs.
So your destructor (or wherever you want to stop listening immediately) for the class could look something like this:
SomeClass::~SomeClass() {
this->handlingEvents = false;
libusb_hotplug_deregister_callback(context, hotplugCallbackHandle);
if (this->thread.joinable()) this->thread.join();
libusb_exit(this->context);
}
In the function:
int libusb_handle_events_completed(libusb_context* ctx, int* completed)
You can change the value of the completed to "1" so the function will return without blocking
According to their docs:
If the parameter completed is not NULL then after obtaining the event
handling lock this function will return immediately if the integer
pointed to is not 0. This allows for race free waiting for the
completion of a specific transfer.
There is no functions in libusb that force libusb_handle_events() to return.
It's recommended to use libusb_handle_events() in a dedicated thread so your main thread will not be blocked by this call. Even though, if you need to manipulate the call of the event handler you can put the call in a while(condition) and change the condition state in your main thread.
Libusb documentation details this here.

Doing an atomic read in objective-C

I have a thread-safe class, a cancel token, that transitions from an unstable mutable state (not cancelled) to a stable immutable state (cancelled). Once an instance has become immutable, I'd like to stop paying the cost of acquiring a lock before checking the state.
Here's a simplification of what things look like now:
-(bool) isCancelled {
#synchronized(self) {
return _isCancelled;
}
}
-(bool) tryCancel {
#synchronized(self) {
if (_isCancelled) return false;
_isCancelled = true;
}
return true;
}
and what I want to try:
-(bool) isCancelled {
bool result;
// is the following correct?
// can the two full barriers be reduced to a single read-acquire barrier somehow?
OSMemoryBarrier();
result = _isCancelled != 0;
OSMemoryBarrier();
return result;
}
-(bool) tryCancel {
return OSAtomicCompareAndSwap32Barrier(0, 1, &_isCancelled);
}
Is using two memory barriers the correct approach? How should I expect it to compare to the cost of acquiring a lock (insert standard refrain about profiling here)? Is there a cheaper way to do it?
Edit: this sounds like possible premature optimization. is this lock acquisition slowing things down?
Edit2: its possible compiler optimization will defeat this. be aware.
if you are concerned about the gotchas with double checked locking, perhaps dispatch_once() could be useful for you?
would double checked locking work in this case?
-(void) doSomething {
if (!_isCanceled) { //only attempt to acquire lock if not canceled already
#synchronized(self) {
if (!_isCanceled) // now check again (the double check part)
doSomethingElse();
}
}
}
read the wikipedia entry on double checked locking for more info

Safely detect, if function is called from an ISR?

I'm developing software for an ARM Cortex M3 (NXP LPC1769) microncontroller. At the moment I'm searching for a mechansim to detect if my function is called within an ISR. I asume that I have to check a register. Based on this information I would like to call difficult functions.
I already checked the reference manual, if there is a register containing the necessary information.
For example I tried to detect if I'm called from an ISR (I used SysTick-ISR) based on the "Interrupt Active Bit Register" (IABR) register. This register should be != 0 if an ISR is active. But the value was 0x00000000. This implies that no interrupt is active. Besides this test I checked the NVIC and SC register in the reference manual searching for a register containing the necessary flag but I didn't found one.
Does anybody know a suitable register / mechanism for my problem?
You need to test the VECTACTIVE field of the Interrupt Control State Register.
I use the following:
//! Test if in interrupt mode
inline bool isInterrupt()
{
return (SCB->ICSR & SCB_ICSR_VECTACTIVE_Msk) != 0 ;
}
SCM and SCB_ICSR_VECTACTIVE_Msk are defined in the CMSIS (core_cm3.h), which I imagine would be included indirectly by your part specific header (lpc17xx.h or similar I guess). I am using C++, including stdbool.h in C will get you a bool type, or change to an int or typedef of your own.
It is then used thus for example:
void somefunction( char ch )
{
if( isInterrupt() )
{
// Do not block if ISR
send( ch, NO_WAIT ) ;
}
else
{
send( ch, TIMEOUT ) ;
}
}
If a solution is required that assumes no knowledge of the architecture consider the following:
volatile int interrupt_nest_count = 0 ;
#define ENTER_ISR() interrupt_nest_count++
#define EXIT_ISR() interrupt_nest_count--
#define IN_ISR() (interrupt_nest_count != 0)
void isrA()
{
ENTER_ISR() ;
somefunction( 'a' ) ;
EXIT_ISR() ;
}
void isrB()
{
ENTER_ISR() ;
somefunction( 'b' ) ;
EXIT_ISR() ;
}
void somefunction( char ch )
{
if( IN_ISR() )
{
// Do not block if ISR
send( ch, NO_WAIT ) ;
}
else
{
send( ch, TIMEOUT ) ;
}
}
However the question refers to safely detecting the interrupt context, and this relies on the enter/exit macros being added to all ISRs.
After some discussion and more searching I found the right register:
Interrupt Program Status Register: The IPSR contains the exception type number of
the current Interrupt Service Routine (ISR). See the register summary in Table 626 for
its attributes.
If a function isn't called from an isr the value of the register is IPSR == 0
The simplest method is to pass the context as a parameter to the function. It is also platform independent.
typedef enum _context {
normal_context = 0,
isr_context = 1
} context;
Call to the function from ISR:
func(param1, param2, isr_context);
Call to the function from normal code:
func(param1, param2, normal_context);
If the ISR code is not under your control and you are just passing a function pointer, then just use two different wrapper functions. One that passes isr_context and another that passes normal_context as a parameter to the function.
The best way is probably to make two different functions: one that is called from the ISR and another that is called from the rest of the program.
If that isn't an option, then you could determine the caller with pure standard C, no registers needed:
inline void my_func (const char* caller);
static void isr (void)
{
my_func(__func__);
}
inline void my_func (const char* caller)
{
if(strcmp(caller, "isr")==0)
{
// was called from isr
}
else
{
// called from elsewhere
}
}
If you give your ISRs smart names, the above code will be quick enough to run from an isr.