Hello I am writing a code using pthread_cond_wait() and pthread_cond_broadcast(). The objective of my code is to trigger four threads at a time which should run in parallel.When I am passing signal to four threads using pthread_cond_broadcast all the four are getting triggered serially.The triggered time for the four threads are as given below.
HH : MM : SS : MS : uS
Thread 1 12 : 59 : 05 : 27 : 407
Thread 2 12 : 59 : 05 : 27 : 586
Thread 3 12 : 59 : 05 : 27 : 879
Thread 4 12 : 59 : 05 : 28 : 113
From the observation we can see that triggered time of four threads are varying so can anyone tell me what is the reason for that?
Related
Trying to translate BASIC code written in the 1990's to Python. I keep coming across two symbols, ! (exclamation mark) and . (period). I can't find any documentation online on what they do.
I have the code running but some of the outputs are not as expected - I am wondering if these might be the issue as I previously thought that the period may just be a typo for a multiplication.
Examples:
|
v
QWLOST = (((TW-TDAO)/(TWRT-TDAOR))^1.25)*((VISR/VIS)^0.25).(PW+PE)*DT
TFAVE = (TTO+TBO)/2!
^
|
In case anyone else in the future needs to know this.
! - defines a single
. - Was just a typo for * (multiplication)
I tried a few things in bwBasic (in Linux, in case that's relevant!).
bwBASIC: list
10: for i = 1 to 20
20: print i, ., . - i
30: next i
40: print ".="; .
This gave me:
bwBASIC: run
1 20 19
2 20 18
3 20 17
4 20 16
5 20 15
6 20 14
7 20 13
8 20 12
9 20 11
10 20 10
11 20 9
12 20 8
13 20 7
14 20 6
15 20 5
16 20 4
17 20 3
18 20 2
19 20 1
20 20 0
.= 20
Which would suggest that . (in bwBasic in any case) is the max number in a for loop.
Continue from: EMV Reading PAN Code
I'm working in C, so I havn't Java tools and all the functions that parse automatically the response of APDU command.
I want to read all types of smart cards.
I have to parse the response of an GET PROCESSING OPTIONS and get the AFL (Access File Locator) of every card.
I have three cards with three different situation:
A) HelloBank: 77 12 82 2 38 0 94 c 10 2 4 1 18 1 1 0 20 1 1 0 90
B) PayPal: 77 12 82 2 39 0 94 c 18 1 1 0 20 1 1 0 28 1 3 1 90
C) PostePay: 80 a 1c 0 8 1 1 0 18 1 2 0 90
Case A)
I've got three different AFL: 10 2 4 1, 18 1 1 0, 20 1 1 0
So I send 00 B2 SFI P2 00 where SFI was 10>>3 (10 was first byte of first AFL) and P2 was SFI<<3|4 and this way I got the correct PAN Code of my card.
Case B)
I've got three different AFL: 18 1 1 0, 20 1 1 0, 28 1 3 1.
So I send 00 B2 SFI P2 00 builded in the same way as Case A, but I got the response 6A 83 for every AFL.
Case C)
I've got two different AFL: 8 1 1 0, 18 1 2 0 but I cannot parse those automatically because there isn't the same TAG of previous response.
If I use those AFL it worked and I can get the PAN Code of the card.
How can I make an universal way to read the correct AFL and how can I make the correct command with those AFL?
Here is the decoding of AFL:
You will get the AFL in multiple of 4 Bytes normally. Divide your complete AFL in a chunk of 4 Bytes. Lets take an example of 1 Chunk:
AABBCCDD
AA -> SFI (Decoding is described below)
BB -> First Record under this SFI
CC -> Last Record under this SFI
DD -> Record involved for Offline Data Authentication (Not for your use for the moment)
Taking your example 10 02 04 01 18 01 01 00 20 01 10 00
Chunks are 10 02 04 01, 18 01 01 00, 20 01 10 00
10 02 04 01 -->
Taking 1st Byte 10 : 00010000 Take initial 5 bits from MSB --> 00010 means 2 : Means SFI 2
Taking 2nd Byte 02 : First Record under SFI 2 is 02
Taking 3rd Byte 04 : Last Record under SFI 2 is 04
Excluding 4 Byte explanation since no use
Summary : SFI 2 contains record 2 to 4
How Read Record command will form :
APDU structure : CLA INS P1 P2 LE
CLA 00
INS B2
P1 (Rec No)02 (SInce in this SFI 2 inital record is 02)
P2 (SFI) SFI 02 : Represent the SFI in 5 binay digit 00010 and then append 100 in the end : 00010100 : In Hex 14
So P2 is 14
LE 00
APDU to Read SFI 2 Rec 2 : 00 B2 02 14 00
APDU to Read SFI 2 Rec 3 : 00 B2 03 14 00
APDU to Read SFI 2 Rec 4 : 00 B2 04 14 00
Now if you will try to Read Rec 5, Since this Rec is not present you will get SW 6A83 in this case.
Use the same procedure for all chunk to identify the available Records and SFIs
BY this mechanisam you can write the function to parse the AFL
I am using Perl v5.16.2
I am using the Net::SMPP modules and it returns me some data.
If I show this data, I get this (simplified) :
$VAR1 = bless( {
'receipted_message_id' => '400002F6E09C61701222120140',
'30' => '400002F6E09C61701222120140'
}, 'Net::SMPP::PDU' );
Now, let's assume this data is in $pdu and I do this :
$message_id = $pdu->{30}; # or $pdu->{receipted_message_id}, same result
myfunction($message_id);
Then, I have myfunction defined as :
sub myfunction {
my $message_id = shift;
my $message_id_static = '400002F6E09C61701222120140';
print Dumper($message_id);
print Dumper($message_id_static);
print hexdump($message_id);
print hexdump($message_id_static);
if ($message_id eq $message_id_static)
{
print "match\n";
}
else
{
print "no match\n";
}
}
The output of the program is :
$VAR1 = '400002F6E09C61701222120140';
$VAR1 = '400002F6E09C61701222120140';
Data::Hexdumper: data length isn't an integer multiple of lines
so has been padded with NULLs at the end.
0x0000 : 34 30 30 30 30 32 46 36 45 30 39 43 36 31 37 30 : 400002F6E09C6170
0x0010 : 31 32 32 32 31 32 30 31 34 30 00 00 00 00 00 00 : 1222120140......
Data::Hexdumper: data length isn't an integer multiple of lines
so has been padded with NULLs at the end.
0x0000 : 34 30 30 30 30 32 46 36 45 30 39 43 36 31 37 30 : 400002F6E09C6170
0x0010 : 31 32 32 32 31 32 30 31 34 30 00 00 00 00 00 00 : 1222120140......
no match
Which doesn't make any sense to me... !
If I try to use $message_id to do a SQLite query, it fails miserably. If I use $message_id_static instead, it works perfectly.
So, is this a weird internal Perl bug, or am I missing something ?
This has been driving me nuts for hours...
EDIT :
Using the perl debugger, I get this :
DB<3> x $message_id_static
0 '400002F6E09C61701222120140'
DB<4> x $message_id
0 "400002F6E09C61701222120140\c#"
So at least I see there is a difference in the strings, but why isn't it seen by the hexdump, and what is that \c# ?
Thanks !
The \c# character is Ctrl-#, which is the ASCII NUL character at code point zero
You can't see it in your hexdump output because it is indistinguishable from the 00 padding at the end of the dump
If you set $Data::Dumper::Useqq = 1 then it will be visible in the output from print Dumper $message_id
You can remove it from the variable by using s/\0\z// or tr/\0//d, but you should really investigate why it is there in the first place
While Reading the files in python using
f = open ("filename.txt")
and accessing the data with
f.read(1)
and finally finding the position of stream usibg
f.tell()
for every step; We get a continous numbering starting from 0 to the current position.
The problem i am facing is that i am actually getting a random number as f.tell() for some positions and then continung the numbers.
For examle, the f.tell() outputs look something ike the following
0
1
2
3
133454568679978
6
7
8...
Any idea why this is happening?
My Code :
f=open("temp_mcompress.cpp")
current = ' '
while current != '' :
print(f.tell())
current = f.read(1)
f.close()
Temp_mcompress.cpp file :
#include <iostream>
int main(int a)
{
}
OUtput :
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
18446744073709551636
18446744073709551638
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
18446744073709551655
40
41
43
44
It seems I might have found the problem which may still be applicable to python 3.x:
source: http://docs.python.org/2.4/lib/bltin-file-objects.html
tell()
Return the file's current position, like stdio's ftell().
Note: On Windows, tell() can return illegal values (after an fgets())
when reading files with Unix-style line-endings. Use binary mode
('rb') to circumvent this problem.
I am trying to understand the way system-calls are invoked on a Linux machine. For this, I ran a guest machine with a Linux 3.0.43 kernel on the QEMU emulator.
In order to know the system call numbers, I instrumented the interrupt function in qemu (do_interrupt_all() in target-i386/seg_helper.c --- not very important). Basically whenever I get an int 0x80 interrupt, I print the value in the EAX register. The output of the run gave the system call numbers. I expected the exec system call for the init process first. Then a fork and some `brk system calls. However, I am not sure if that is what I got. I am printing the first 100 system call numbers here. My guest is a 64-bit machine. Here is an online code exploration for my kernel.
: 11
: 45
: 33
: 192
: 33
: 5
: 197
: 192
: 6
: 33
: 5
: 3
: 197
: 192
: 192
: 192
: 6
: 192
: 243
: 125
: 125
: 125
: 91
: 122
: 45
: 45
: 197
: 5
: 5
: 5
: 5
: 221
: 141
: 141
: 6
: 5
: 5
: 5
: 5
: 5
: 197
: 192
: 3
: 3
: 6
: 91
: 5
: 197
: 192
: 3
: 3
: 6
: 91
: 5
: 197
: 192
: 3
: 3
: 6
: 91
: 5
: 197
: 192
: 3
: 3
: 6
: 91
: 5
: 197
: 192
: 3
: 3
: 6
: 91
: 5
: 197
: 192
: 3
: 3
: 6
: 91
: 5
: 5
: 197
: 192
: 3
: 3
: 6
: 91
: 5
: 197
: 192
: 3
: 3
: 6
: 91
: 5
: 197
Yes, it's what you got (Linux System Call Numbers, 64-bit Linux System Call Numbers):
11 : sys_exevce, or exec's system call
45 : sys_brk, the thing under malloc
33 : sys_access
192 : lgetxattr
And so on.