1

Topic: How the function variable in the multi-threaded program behaves static?

There is a function which returns a parameter continuity. I.e.
To it transferred 1, it returned false (the first value obviously not continuously)
To it transferred 2, it returned true
To it transferred 3, it returned true
To it transferred 5, it returned false
To it transferred 6, it returned true
...
It would be desirable inside this function to save the previous value with the help static - a variable. But in an Internet did not find anything sensible on behavior static - variables in the multi-threaded program.
What will the flight tells?

2

Re: How the function variable in the multi-threaded program behaves static?

Found new possibilities With ++:

static thread_local int PreviousNumber;

If I created flows by means of Qt logically too should fly up. Somebody tried such possibilities? What reefs (productivity does not fall)?

3

Re: How the function variable in the multi-threaded program behaves static?

AlekseySQL wrote:

found new possibilities With ++:

static thread_local int PreviousNumber;

To do functions with static-parameter is not abruptly. . Better it somehow to renew.

4

Re: How the function variable in the multi-threaded program behaves static?

mayton wrote:

to Do functions with static-parameter is not abruptly. . Better it somehow to renew.

But the code is not tangled: it is not necessary above on two levels on a stack to store value of the previous value and twice deep into it under the link ... Mahlo who understands this perversion.

5

Re: How the function variable in the multi-threaded program behaves static?

Why - that at assignment of value of a similar variable the program takes off with an error:

inline char GetContinuousNumber (ullong Number)
{
static thread_local ullong PreviousNumber;
if (Number - PreviousNumber == 1)
{
PreviousNumber = Number;//THE ERROR!!!
return 1;
}
else
{
PreviousNumber = Number;//THE ERROR!!!
return 0;
}
}

6

Re: How the function variable in the multi-threaded program behaves static?

AlekseySQL wrote:

the program takes off with an error

And this error "" or "  "?
inline to begin with remove.

7

Re: How the function variable in the multi-threaded program behaves static?

AlekseySQL;
So directly also writes: "the ERROR!!!"?)))

8

Re: How the function variable in the multi-threaded program behaves static?

Anatoly Moskovsky wrote:

AlekseySQL;
So directly also writes: "the ERROR!!!"?)))

The error looks so: "Application received a signal from an operating system and will be closed". On behavior it is very similar to an error of operation with storage and when I work without stastic - a variable (by means of transmission to function of the link to the previous value), any errors not  and the program is successfully completed. So an error not in the remaining code of the program, namely in operation with static - a variable.

9

Re: How the function variable in the multi-threaded program behaves static?

AlekseySQL wrote:

why - that at assignment of value of a similar variable the program takes off with an error:

inline char GetContinuousNumber (ullong Number)
{
static thread_local ullong PreviousNumber;
if (Number - PreviousNumber == 1)
{
PreviousNumber = Number;//THE ERROR!!!
return 1;
}
else
{
PreviousNumber = Number;//THE ERROR!!!
return 0;
}
}

Such variable value should be appropriated at the declaration, it seems:

static thread_local ullong PreviousNumber = 0;

10

Re: How the function variable in the multi-threaded program behaves static?

AlekseySQL wrote:

the Error looks so: "Application received a signal from an operating system and will be closed".

There still the button of particulars is normally applied on such message. And possibility
To launch a debugger. Very useful.

11

Re: How the function variable in the multi-threaded program behaves static?

12

Re: How the function variable in the multi-threaded program behaves static?

Here on sense - not function and object with a state. If so to make that and in flows
It to interpose conveniently and conflicts will not be.

13

Re: How the function variable in the multi-threaded program behaves static?

If it is necessary, that in each flow there was a separate counter:

static thread_local uint64_t PreviousNumber = 0;

If it is necessary that in all flows there was a same counter:

static std:: atomic <uint64_t> PreviousNumber (0);

14

Re: How the function variable in the multi-threaded program behaves static?

Utkin wrote:

If it is necessary, that in each flow there was a separate counter:

static thread_local uint64_t PreviousNumber = 0;

If it is necessary that in all flows there was a same counter:

static std:: atomic <uint64_t> PreviousNumber (0);

Thanks, tomorrow I will check up! I correctly understand, what data types with a postfix _t have been entered in With ++ 11 to remove a question platformo - dependences of the size in storage? In other words, if it is supposed to use the program on different platforms it is better to use these types, instead of standard int, long, long long?

15

Re: How the function variable in the multi-threaded program behaves static?

Like so should be, without static

thread_local ullong PreviousNumber;

For me works everywhere, except DLL under XP, there there is a problem with TLS.

16

Re: How the function variable in the multi-threaded program behaves static?

Just in case:
thread_local It not one variable, and on one on each flow, i.e. is so much variables, how many flows. Speech about normal static can all the same? About that and another already wrote

17

Re: How the function variable in the multi-threaded program behaves static?

AlekseySQL wrote:

it is passed...
Thanks, tomorrow I will check up! I correctly understand, what data types with a postfix _t have been entered in With ++ 11 to remove a question platformo - dependences of the size in storage? In other words, if it is supposed to use the program on different platforms it is better to use these types, instead of standard int, long, long long?

Yes, uint64_t... - entered for accurate understanding of its size, for binary compatibility and code maintainability.
When use short, int, long, long long... - that  on one architecture, then is caught by overflow bugs on another.
When I precisely know that there values will be very small I use int.
ullong - of this kind is not present, it should user be defined.

18

Re: How the function variable in the multi-threaded program behaves static?

AlekseySQL wrote:

There is a function which returns a parameter continuity. I.e.
To it transferred 1, it returned false (the first value obviously not continuously)
To it transferred 2, it returned true
To it transferred 3, it returned true
To it transferred 5, it returned false
To it transferred 6, it returned true
...
It would be desirable inside this function to save the previous value with the help static - a variable. But in an Internet did not find anything sensible on behavior static - variables in the multi-threaded program.
What will the flight tells?

static a variable one, flows much... Cannot work basically.
Such design of function is conceived as . It is bad
In such type it is necessary to apply state saving to function operation in variables, storable in thread local storage. Thus it is not mandatory, that it there was a function static variable.
It would be even better to change design of function so that stored a state and the client of this function transferred it  function.
Then it would be not necessary to store anything in thread local storage (which application unconditionally is awfully bad architectural decision)

19

Re: How the function variable in the multi-threaded program behaves static?

AlekseySQL wrote:

it is passed...
But the code is not tangled: it is not necessary above on two levels on a stack to store value of the previous value and twice deep into it under the link ... Mahlo who understands this perversion.

Make it a class, and anybody even words does not tell... Simply even nobody understands.

20

Re: How the function variable in the multi-threaded program behaves static?

Utkin wrote:

Yes, uint64_t... - entered for accurate understanding of its size, for binary compatibility and code maintainability.
When use short, int, long, long long... - that  on one architecture, then is caught by overflow bugs on another.
When I precisely know that there values will be very small I use int.

, and in that case it is possible to guarantee minimum / the maximum value storable in these types? Or it turns out as a principle of Heisenberg: or we guarantee the size on a disk (* _t types), or we guarantee the size of storable value (normal types from), and simultaneously to give both warranties it is impossible?

21

Re: How the function variable in the multi-threaded program behaves static?

For integer numbers the size on a disk defines mines/maks value:
0... 2^N
Sign-2^N-1... 2^N-1

22

Re: How the function variable in the multi-threaded program behaves static?

AlekseySQL wrote:

or we guarantee the size on a disk (* _t types), or we guarantee the size of storable value (normal types from, and simultaneously to give both warranties it is impossible?

Problem in that that normal types guarantee is minimum-possible value

https://ru.wikipedia.org/wiki/___C wrote:

the Real size of integral types depends on implementation. The standard only stipulates relations in sizes between types and minimum frames for each type:
So long long should not be less long which in turn should not be less int which in turn should not be less short. As char - least of possible addressed types, other types cannot have the size less it.
The minimum size for char - 8 bits, for short and int - 16 bits, for long - 32 bits, for long long - 64 bits.
It is desirable, that the type int was such integral type with which the processor most effectively works. It allows to reach high flexibility, for example, all types can occupy 64 bits. However, there are the popular circuits describing the sizes of integral types. [7]
In practice it means that char occupies 8 bits, and short 16 bits (also, as well as them  analogs). int on the majority of the modern platforms occupies 32 bits, and long long 64 bits. The length long varies: for Windows it is 32 bits, for UNIX-like systems - 64 bits.

23

Re: How the function variable in the multi-threaded program behaves static?

AlekseySQL wrote:

It would be desirable inside this function to save the previous value with the help static - a variable.

I do not love static variables. Easier in the first parameter to transfer functions the pointer on on certain . If value  NULL it is the first call and function itself selects storage and places the pointer on it in . By the subsequent calls function will use this selected storage at own discretion.
It is possible as to transfer at once , instead of the pointer to it. But then function of initialization of it  is required still. Well as analog open () before read ().

24

Re: How the function variable in the multi-threaded program behaves static?

AlekseySQL wrote:

it is passed...
, and in that case it is possible to guarantee minimum / the maximum value storable in these types? Or it turns out as a principle of Heisenberg: or we guarantee the size on a disk (* _t types), or we guarantee the size of storable value (normal types from), and simultaneously to give both warranties it is impossible?

In a subject of favor of serialization. Besides digit capacity there is also the order a byte in a machine word.
Little/Big endian is called. And about this aspect the head is ill when it is necessary to provide migration
(data) from one iron on .

25

Re: How the function variable in the multi-threaded program behaves static?

Utkin wrote:

If it is necessary, that in each flow there was a separate counter:

static thread_local uint64_t PreviousNumber = 0;

If it is necessary that in all flows there was a same counter:

static std:: atomic <uint64_t> PreviousNumber (0);

Thanks, flied up!
p.s. On operation there was a fire therefore long could not check up.

Posts [ 1 to 25 of 27 ]

Pages 1 2 Next

You must login or register to post a reply