Semaphore and multithread

jsulm

@Montanaro said in Semaphore and multithread:

check_for_interrupt blocks the resource

I'm not talking about blocking a resource. I'm simply asking whether check_for_interrupt blocks for longer time or returns immediately.
And again: why do you think you need semaphore if you do not use any threads?

J.Hilk

@Montanaro

here's the thing, multithreading /parallelization is not trivial. You'll need a good understanding of what you're doing or you end up, at best, wasting lots of time or at worst you shoot yourself in the foot.

Expert suggest me to put semaphore in.

I highly doubt that expert status. What is the reasoning behind that statement, please explain

think I can use that:
https://doc.qt.io/archives/qt-4.8/qmutexlocker.html

The point of a Semaphore is not to use a mutex

does check_for_interrupt actually take time at all ? And if it does how long. And what does it do exactly. There are other ways to do this, much more neater/higher level ones that mutex or semaphores especially in Qt

Montanaro

@jsulm
well Experts tell me that code (ui or check_for_interrupt) can occupy the resource while the other line of code ( ui or check_for_interrupt) starts. I 'm beginner so I dont know if it's true but it's mandatory to check that for me.

JonB

@Montanaro
You have now been asked about 3 times whether your check_for_interrupt() is blocking or returns immediately? Are you going to answer to help those who are trying to help you, or are you going to just ignore the question?

On a separate matter, it is up to you whether you want to follow the "experts'" advice you have received elsewhere, or whether you want to listen to the "experts" here as well? I do not count myself among the "experts", but there are others posting here who are experts (especially in matters Qt, which your other advisors may not be), so you might want to weigh their comments against those you have received from elsewhere.

Montanaro

@J-Hilk

I dont know.
He (my senior) suggests me to use that :
https://doc.qt.io/archives/qt-4.8/qmutexlocker.html
so I must try.

I have two task:

checking_for_interrupt. this function reads the time of flight sensor and its results are for example 120, 150, 180 (millimeter) when I dont use ui. And those results are phisically correct
only ui shows me the number and text on my display, for example: "the distance is …. mm"

but when I use together (ui and check_for_interrupt), the results of time of flight are: 3000, 3000, 3000, 3000, 3000 and it 's not possible

jsulm

@Montanaro Do you mean if you comment out

ui->label->setText("il valore della distanza in mm è: " + QString::number(distance));

in

unsigned char MainWindow::poll()
{
    unsigned short distance;
        qDebug() << " Polling started";

         check_for_interrupt(ADDR, &distance); 
        
            qDebug() << "valore distanza:" << distance;
 
            ui->label->setText("il valore della distanza in mm è: " + QString::number(distance));

    
        }

qDebug() << "valore distanza:" << distance;
prints correct values?

Montanaro

@JonB

check_for_interrupt returns immediately but always the same result ( I visually dont note difference )

Well… I understand your suggest but if I dont try to put mutex in, I dont accomplish my task and my senior dont countenance me :(

@jsulm : no. check_for_interrupt (with ui) prints uncorrect values. it's the problem

so thanks to all :)

jsulm

@Montanaro said in Semaphore and multithread:

no. check_for_interrupt (with ui) prints uncorrect values. it's the problem

That's why I segested to to comment out this line

ui->label->setText("il valore della distanza in mm è: " + QString::number(distance));

and see what happens.
Or do you mean something different if you write "with ui", because I really don't understand the problem.
"when I dont use ui" - what does this mean exactly? Do you mean an app without UI works?

Montanaro

@jsulm

I wrote the code without ui and it works. Then I wrote ui->label->setText("il valore della distanza in mm è: " + QString::number(distance)); into my code and code works with time of 1 second (its resultes are correct) and code doesnt work with time of 500 ms (its results are bad)

I dont understant why.

Senior suggest me that the resource is occuped by the other process

@jsulm I think you are right.
If with ui.label or without ui.label, I Always have ui in my code. But I'm not the boss and I have task :D

J.Hilk

@Montanaro
ok, just to make sure, so that I'm not going crazy:

unsigned char MainWindow::poll()
{
    unsigned short distance;
    qDebug() << " Polling started";

    check_for_interrupt(ADDR, &distance); 
        
    qDebug() << "valore distanza:" << distance;
 
    //ui->label->setText("il valore della distanza in mm è: " + QString::number(distance));
}

Results in the correct read of
120 distance
150 distance
180 distance

but

unsigned char MainWindow::poll()
{
    unsigned short distance;
    qDebug() << " Polling started";

    check_for_interrupt(ADDR, &distance); 
        
    qDebug() << "valore distanza:" << distance;
 
    ui->label->setText("il valore della distanza in mm è: " + QString::number(distance));
}

results in
3000 distance
3000 distance
3000 distance

?

JonB

@Montanaro
First, please answer @J-Hilk's latest question.

There must be more going on in your code somewhere than you show... And for my part at least, I don't understand what the "resource" you refer to is....

I suggest you briefly test one more case. Try having:

    qDebug() << "valore distanza:" << QString::number(distance);  // <- this is changed, it uses `QString::number`
 
    // next line is still commented out
    //ui->label->setText("il valore della distanza in mm è: " + QString::number(distance));

Does this produce right or wrong output? If by any chance this also produces wrong output, it suggests that any call to a Qt method is causing a problem, not the label->setText() itself.

Montanaro

@J.Hilk

Yes. your summary is right

@JonB thanks. I try your suggest (In check_interrupt, I use ioctl to read i2c from dev/usb/myDevice)

JonB

@Montanaro
Depending on your call to ioctl, it could be a blocking or non-blocking call, which is what we have asked you about with success....