How to stop when blocked.

I hit an interesting challenge when working with SMF-real-time.

An application can connect to the SMF real time service, and it will be sent data as it is produced. Depending on a flag the application can use:

  • Non blocking. The application gets a record if there is one available. If not it gets are return code saying “No records available”.
  • Blocking. The application waits (potentially for ever) for a record.

Which is the best one to use?

This is a general problem, it not just SMF real time that has these challenges.

What are the options- generally?

Non blocking

You need to loop to see if there are records, and if not wait. The challenge is how long should you wait for. If you wait for 10 seconds, then you may get a 10 second delay between the record being created, and your application getting it. If you specify a shorter time you reduce this window. If you reduce the delay time, then the application does more loops per minute and so there is an increase in CPU cost.

Blocking

If you use blocking – there is no extra CPU looping round. The problem is how to do you stop processing your application cleanly when it is in a blocked wait, to allow cleaning up at the end of the processing.

A third way

MQSeries process application messages asynchronously. You can say wait for a message – but time out after a specified time interval if no messages have been received.

This method is very successful. But some application abused it. They want their application to wake up every n second, and check their application’s shutdown flag. If their flag is set, then shutdown.

The correct answer in this case is to have MQ Post an Event Control Block(ECB), the application’s code posts another ECB; gthe mainline code waits for either of the EBCs to be posted, and take the appropriate action. However the lazy way of sleeping, waking, checking and sleeping is quick and easy to code.

What are the options for SMF real time?

With the SMF real time code, while one thread is running – and in a blocked wait, another thread can issue a disconnect() request. This wakes up the waiting thread with a “you’ve been woken up because of a disconnect” return code.

The solution is to use a threading model.

The basic SMF get code

while True:
x, rc = f.get(wait=True) # Blocking get
if x == "" : # Happens after disc()
print("Get returned Null string, exiting loop")
break
if rc != "OK":
print("get returned",rc)
print("Disconnect",f.disc())
i += 1
# it worked do something with the record
...
print(i, len(x)) # Process the data
...

Make the SMF get a blocking get with timeout

With every get request, create another thread to wake up and issue the disconnect, to cause the blocked get to wake up.

This may be expensive doing a timer thread create and cancel with every record.

def blocking_get_loop(f, timeout=10, event=None,max_records=None,):
i = 0
while True:
t = Timer(timeout, timerpop(f)) # execute the timeout function after 10 seconds
x, rc = f.get(wait=True) # Blocking get
t.cancel()

....


# This wakes after the specified interval then executes.
def timerpop(f):
f.disc()

Wait for a terminal interrupt

Vignesh S sent me some code which I’ve taken and modified.

The code to the SMF get is in a separate thread. This means the main thread can execute the disconnect and wake up the blocked request.

# Usage example: run until Enter or interrupt, or max_records
if __name__ == "__main__":
blocking_smf(max_records=6) # execute the code below.

def blocking_smf(stream_name="IFASMF.INMEM", debug=0, max_records=None):
f = pySMFRT(stream_name, debug=debug)
f.conn(stream_name,debug=2) # Explicit connect

# Start the blocking loop in a separate thread
get_thread = threading.Thread(target=mainlogic,args=(f),kwargs={"max_records": 4}))
get_thread.start()


try:
# Main thread: wait for user input to stop
input("Press Enter to stop...\n")
print("Stopping...")
except KeyboardInterrupt:
print("Interrupted, stopping...")
finally:
f.disc() # This unblocks the get() call
get_thread.join() # Wait for thread to exit

The key code is

get_thread = threading.Thread(target=mainlogic,args=(f),kwargs={"max_records": 4}))
get_thread.start()

This attaches a thread, execute the function mainlogic, passing the positional parameters f, and keyword arguments max_records.

The code to do the gets and process the requests is the same as before, with the addition of the count of records processed.

def blocking_get_loop(f, max_records=None):
i = 0
while True:
x, rc = f.get(wait=True) # Blocking get
if x == "" : # Happens after disc()
print("Get returned Null string, exiting loop")
break
if rc != "OK":
print("get returned",rc)
print("Disconnect",f.disc())
i += 1
# it worked do something with the record
...
print(i, len(x)) # Process the data
...
#
if max_records and i >= max_records:
print("Reached max records, stopping")
print("Disconnect",f.disc()) # clean up if ended because of number of records
break

If the requested number of records has been processed, or there has been an error, or unexpected data, then disconnect is called, and the function returns.

Handle a terminal interrupt

The code

try:
# Main thread: wait for user input to stop
input("Press Enter to stop...\n")
print("Stopping...")
except KeyboardInterrupt:
print("Interrupted, stopping...")
finally:
f.disc() # This unblocks the get() call
get_thread.join() # Wait for thread to exit

waits for input from the terminal.

This solution is not perfect because if the requested number of records are processed quickly, you still have to enter something at the keyboard.

Use an event with time out

One problem has been notifying the main task when the SMF get task has finished. You can use an event for this.

In the main logic have

def blocking_smf(stream_name="IFASMF.INMEM", debug=0, max_records=None):
f = pySMFRT(stream_name, debug=debug)
f.conn(stream_name,debug=2) # Explicit connect
myevent = threading.Event()

# Start the blocking loop in a separate thread
get_thread = threading.Thread(target=blocking_get_loop, args=(f,),
kwargs={"max_records": max_records,
"event":myevent})
get_thread.start()
# wait for the SMF get task to end - or the event time out
if myevent.wait(timeout=30) is False:
print("We timed out")
f.disc() # wakeup the blocking get

get_thread.join # Wait for it to finish

In the SMF code

def blocking_get_loop(f, t,max_records=None, event=None):
i = 0
while True:
#t = Timer(timeout, timerpop(f))
x, rc = f.get(wait=True) # Blocking get
#t.cancel()
if x == "" : # Happens after disc()
print("Get returned Null string, exiting loop")
break
if rc != "OK":
print("get returned",rc)
print("Disconnect",f.disc())
i += 1
print(i, len(x)) # Process the data
if max_records and i >= max_records:
print("Reached max records, stopping")
print("Disconnect",f.disc())
break
if event is not None:
event.set() # wake up the main task

s

Why oh why is my application waiting?

I’ve been working on a presentation on performance, and came up with an analogy which made one aspect really obvious…. but I’ll come to that.

This blog post is a short discussion about software performance, and what affects it.

Obvious statement #1

The statement used to be An application is either using, CPU, or waiting. I prefer to add or using CPU and waiting which is not obvious unless you know what it means.

Obvious statement #2

All applications wait at the same speed. If you are waiting for a request from a remote server, it does not matter how fast your client machine is.

Where can an application wait?

I’ll go from longest to shortest wait times

Waiting for the end user

If you have displayed a menu for an end user to complete, you might wait minutes (or hours) for the end user to complete the information and send it.

Waiting for a remote request

This can be a request to a remote server to do something. This could be to buy something, or simple web look up, or a Name Server lookup. These should all be under a second.

Waiting for disk I/O

If your application is doing database work, such as DB2 there can be many disk I/Os. Any updates are logged to disk for recovery purposes. If your disk response time is typically 1 ms, then you may have to wait several milliseconds. When your application issues a commit, and wants to log data – there will likely to be an I/O in progress – so you have to wait for that I/O to complete before any more data can be written. Typically a database can write 16 4KB pages at a time. If the database logging is very active you may have to wait until any queued data in log buffers is written, before your application’s data can be written. An I/O consists of a set up followed by data transmission. The set up time is usually pretty constant – but more data takes more time to transfer. Writing 16 * 4 KB pages will usually take longer than writing one 4KB page.

An application writing to a file may buffer up several records before writing one record to the external medium. You application wrote 10 records, but there was only one I/O.

These I/Os should be measured in milliseconds (or microseconds).

Database and record locks

If your application want to update some information in a database record it could do

  • Get record for update (this prevents other threads from updating it)
  • Display a menu for the end user to complete
  • When the form has been completed, update the record and commit.

This is an example of “Waiting for the end user”. Another application wanting to update the same record may get an “unavailable” response, or wait until the first application has finished.

You can work around this using logic like

  • Each record has a last updated timestamp.
  • Read the record note the last updated timestamp, display the menu
  • When the form has been completed..
    • Read the record for update from the database, and check the “last updated time”.
    • If the time stamp matches the saved value, update the information and commit the changes.
    • If the time stamp does not match, then the record has been updated – release it, and go to the top and try again.

Coupling Facility access

This is measured in 10s of microseconds. The busier the CF is, the longer requests take.

Latches

Latches are used for serialisation of small sections of code. For example updating storage chains.

If you have two queues of work elements, one queued work, on in-progress work. In a single threaded application you can move a work element between queues. With multiple threads you need some form of locking.

In its simplest form it is

pthread_mutex_lock(mymutex)
work = waitqueue.pop()
active.push(work)
pthread_mutex_unlock(mymutext)

You should design your code so few threads have to wait.

Waiting for CPU

This can be due to

  • The LPAR is constrained for CPU; other work gets priority, and your application is not dispatched.
  • The CEC (physical box) is constrained for CPU and your LPAR is not being dispatched.

If your LPAR has been configured to use only one CPU, and there is space capacity in the CEC your LPAR will not be able to use it.

Waiting for paging etc

In these days of lots of real storage in the CEC, waiting for paging etc is not much of an issue. If the virtual page you want is not available to you the operating system has to allocate the page, and map it to real storage.

Waiting for data – using CPU and waiting.

Some 101 education on computer Z architecture

  • The processors for the z architecture are in books. Think of a book as being a physical card which you can plug/unplug from a rack.
  • You can have multiple books.
  • Each book has one or more chips
  • Each chip has one or more CPUs.
  • There is cache (RAM) for each CPU
  • There is cache for each chip
  • There is cache for each book
  • At a hardware level, when you are updating a real page, it is locked to your CPU.
  • If another CPU wants to use the same real page, it has to send a message to the holding CPU requesting exclusive use
  • The physical distance between two CPUs on the same chip is measured in millimeters
  • The distance between two CPUs in the same book is measured in centimeters
  • The distance between two CPUs in different books could be a metre.
  • The time to send information depends on the distance it has to travel. Sharing data between data two CPUs on the same chip will be faster than sharing data between CPUs in different books.

Some instructions like compare and swap are used for serialising access to one field.

  • Load register 4 with value from data field. This could be slow if the real page has to be got from another CPU. It could be fast it the storage is in the CPU, chip or book cache.
  • Load register 5 with new value
  • Compare and swap does
    • Get the exclusive lock on the data field
    • If the value of the data field matches the value in register 4 (the compare)
    • then replace it with the value in register 5 (the swap)
    • else say mismatch
    • Unlock

These instruction (especially the first load) can take a long time, especially if the data field is “owned” by another CPU, and the hardware has to go and get the storage from another CPU in a different book, a metre away.

A common technique for Compare and Swap is to have a common trace table. Each thread gets the next free element, and sets the next free. With many CPU’s actively using the Compare and Swap, these instructions could be a major bottleneck.

A better design is to give each application thread their own trace buffer to avoid the need for a serialisation instruction, and so there is no contention.

Storage contention

We finally get to the bit with the analogy to explain storage contention

You have an array of counters with one slot for each potential thread. You have 16 threads, your array is size 16.

Each thread keeps updates its counter regularly.

Imaging you are sitting in a class room listening to me lecture about performance and storage contention.

I have a sheet of paper with 16 boxes drawn on it.
I pick a person in the front row, and ask them to make a tick on the page in their box every 5 seconds.

Tick, tick, tick … easy

Now I introduce a second person and it gets harder. The first person make a tick – I then walk the piece of paper across the classroom to the second person, who makes a tick. I walk back to the first, who makes another tick etc

This will be very slow.

It gets worse. My colleague is giving the same lecture upstairs. I now do my two people, then go up a floor, so someone in the other classroom can make a mark. I then go back down to my class room and my people (who have been waiting for me) can then make their ticks.

How to solve the contention?

The obvious answer is to give each person their own page, and there is no contention. In hardware terms it might be a 4KB page – or it may be a 256 cache line.

I love this analogy; it has many levels of truth.

Getting from C enumerations to Python dicts.

I wanted to create Python enumerates from C code. For example with system ssl, there is a datatype x509_attribute_type.

This has a definition

typedef enum {                                                                    
x509_attr_unknown = 0,
x509_attr_name = 1, /* 2.5.4.41 */
x509_attr_surname = 2, /* 2.5.4.4 */
x509_attr_givenName = 3, /* 2.5.4.42 */
x509_attr_initials = 4, /* 2.5.4.43 */
...
} x509_attribute_type;

I wanted to created

x509_attribute_type = {
"x509_attr_unknown" : 0,
"x509_attr_name" : 1,
"x509_attr_surname" : 2,
"x509_attr_givenName" : 3,
"x509_attr_initials" : 4,
...
}

I’ve done this using ISPF macros, but thought it would be easier(!) to automate it.

There is a standard way for compilers to products information for debuggers to understand the structure of programs. DWARF is a debugging information file format used by many compilers and debuggers to support source level debugging. The data is stored internally using Executable and Linkable Format(ELF).

Getting the DWARF file

To get the structures into the DWARF file, it looks like you have to use the structure, that is, if you #include a file, by default the definitions are not stored in the DWARF file.

When I used

#include <gskcms.h>
...
x509_attribute_type aaa;
x509_name_type nt;
x509_string_type st;
x509_ecurve_type et;
int l = sizeof(aaa) sizeof(nt) + sizeof(st) + sizeof(et);

I got the structures x509_attribute_type etc in the DWARF file.

Compiling the file

I used USS xlc command with

xlc ...-Wc,debug(FORMAT(DWARF),level(9))... abc.c

or

/bin/xlclang -v -qlist=d.lst -qsource qdebug=format=dwarf -g -c abc.c -o abc.o

This created a file abc.dbg

The .dbg file includes an eye catcher of ELF (in ASCII)

I downloaded the file in binary to Linux.

There are various packages which are meant to be able to process the file. The only one I got to work successfully was dwarfdump. The Linux version has many options to specify what data you want to select and how you want to report it. dwarfdump reported some errors, but I got most of the information out.

readelf displays some of the information in the file, but I could not get it to display the information about the variables.

What does the output from dwarfdump look like?

The format has changed slightly since I first used this a year or so ago. The data are not always aligned on the same columns, and values like <146> and 2426 (used as a locator id) are now hexadecimal offsets.

The older format

<1>< 2426>      DW_TAG_subprogram
DW_AT_type <146>
DW_AT_name printCert
DW_AT_external yes
...
<2>< 2456> DW_TAG_formal_parameter
DW_AT_name id
DW_AT_type <10387>
...

The newer format

< 1><0x0000132d>    DW_TAG_typedef
DW_AT_type <0x00001349>
DW_AT_name x509_attribute_type
DW_AT_decl_file 0x00000002
DW_AT_decl_line 0x000000a7
DW_AT_decl_column 0x00000003
< 1><0x00001349> DW_TAG_enumeration_type
DW_AT_name __3
DW_AT_byte_size 0x00000002
DW_AT_decl_file 0x00000002
DW_AT_decl_line 0x00000091
DW_AT_decl_column 0x0000000e
DW_AT_sibling <0x00001553>
< 2><0x00001356> DW_TAG_enumerator
DW_AT_name x509_attr_unknown
DW_AT_const_value 0
< 2><0x0000136a> DW_TAG_enumerator
DW_AT_name x509_attr_name
DW_AT_const_value 1

Some of the fields are obvious… others are more cyptic, with varying levels of indirection.

  • <1><0x0000132d> is a high level object <1> with id <0x0000132d>
    • DW_TAG_typedef is a typedef
    • DW_AT_type <0x00001349> see <0x00001349> for the definition (below)
    • DW_AT_name x509_attribute_type is the name of the typedef
    • DW_AT_decl_file 0x00000002 there is a file definition #2… but I could not find it
    • DW_AT_decl_line 0x000000a7 the position within the file
    • DW_AT_decl_column 0x00000003
  • < 1><0x00001349> DW_TAG_enumeration_type. This is referred to by the previous element
    • DW_AT_name __3 this an internally generated name
  • < 2><0x00001356> DW_TAG_enumerator This is part of the <1> <0x00001349> above. It is an enumerator.
    • DW_AT_name x509_attr_unknown this is the label of the value
    • DW_AT_const_value 0 with value 0
  • the next is label x509_attr_name with value 1

Other interesting data

I have a function

int colin(char * cinput, gsk_buffer * binput )
{
...
}
and
typedef struct _gsk_data_buffer {
gsk_size length;
void * data;
} gsk_data_buffer, gsk_buffer;

Breaking this down into its parts, there is an entry in the DWARF output for “int”, “colin”, “*”, “char”, “cinput”, “*”, gsk_buffer (which has levels within it), “binput”

< 1><0x0000009a>    DW_TAG_base_type
DW_AT_name int
DW_AT_encoding DW_ATE_signed
DW_AT_byte_size 0x00000004

< 1><0x00000142> DW_TAG_subprogram
DW_AT_type <0x0000009a>
DW_AT_name colin
DW_AT_external yes(1)
...
< 2><0x0000015c> DW_TAG_formal_parameter
DW_AT_name cinput
DW_AT_type <0x00001fa9>

< 2><0x00000173> DW_TAG_formal_parameter
DW_AT_name binput
DW_AT_type <0x00001fb5>
:

< 2><0x0000018a> DW_TAG_variable
DW_AT_name __func__
DW_AT_type <0x00001fc0>

for cinput

< 1><0x00001fa9>    DW_TAG_pointer_type
DW_AT_type <0x0000006e>
DW_AT_address_class 0x0000000a
< 1><0x0000006e> DW_TAG_base_type
DW_AT_name unsigned char
DW_AT_encoding DW_ATE_unsigned_char
DW_AT_byte_size 0x00000001

For binput

  • binput (1fbf) -> DW_TAG_pointer_type (1e2e) -> gsk_buffer (1e41) -> _gsk_data_buffer of length 8.
  • _gsk_data_buffer has two component
    • length _> gsk_size…
    • data (1faf) -> pointer_type (13c)-> unspecified type void

Processing the data in the file

Parse the data

For an entry like DW_AT_type <0x0000006e> which refers to a key of <0x0000006e>. The definition for this could be before after the current entry being processed.

I found it easiest to process the whole file (in Python), and build up a Python dictionary of each high level defintion.

I could then process the dict one element at a time, and know that all the elements it refers to are in the dict.

There are definitions like

typedef struct _x509_tbs_certificate { 
x509_version version;
gsk_buffer serialNumber;
x509_algorithm_identifier signature;
x509_name issuer;
x509_validity validity;
x509_name subject;
x509_public_key_info subjectPublicKeyInfo;
gsk_bitstring issuerUniqueId;
gsk_bitstring subjectUniqueId;
x509_extensions extensions;
gsk_octet rsvd[16];
} x509_tbs_certificate;

Some elements like x509_algorithm_identifier have a complex structure, which refer to other structures. I think the maximum depth for one of the structures was 6 levels deep.
If you are processing a structure you need to decide how many levels deep you process. For the enumeration I was just interested in the level < 1> and < 2> definitions and ignored any below that depth.

For each < 1> element, there may be zero or more < 2> elements. I added each < 2> element to a Python list within the < 1> element.

You may decide to ignore entries such as which file, row or column a definition is in.

My Python code to parse the file is

fn = "./dwarf.txt"
with open(fn) as fp:
# skip the stuff at the front
for line in fp:
if line[0:5] == "LOCAL":
break
all = {} # return the data here
for line in fp:
# if the line starts with ".debug" we're done
if line[0:6] == ".debug":
break
lhs = line[0:4]
# do not process nested requests
if line[0:1] == "<":
if lhs in ["< 1>","< 2>"]:
keep = True
else:
keep = False
else:
if line[0:1] != " ":
continue
if keep is False: # only within <1> and <2>
continue
# we now have records of interest < 1> and < 2> and records underneath them
if line[0:4] == "< 1>":
key = line[4:16].strip() # "< 123>"
kwds1 = {}
all[key] = kwds1
kwds1["l2"] = [] # empty list to which we add
state = 1 # <1> element
kwds1["type"] = line[20:-1]
elif line[0:4] == "< 2>":
kwds2 = {}
kwds1["l2"].append(kwds2)
kwds2["type"] =line[21:-1]
state = 2 # <2> element
else:
tag = line[0:47].strip()
value = line[47:-1].strip()
if state == 1:
kwds1[tag] = value
else:
kwds2[tag] = value

Process the data

I want to look for the enumerate definitions and only process those

print("=================================")
for e in all:
d = all[e]
if d["type"] == "DW_TAG_typedef": # only these
print(d["DW_AT_name"],"{")
at_type = d["DW_AT_type" ] # get the key of the value
l = all[at_type]["l2"] # and the <2> elements within it
for ll in l:
if "DW_AT_const_value" in ll:
print(' "'+ll["DW_AT_name"]+'":',ll["DW_AT_const_value"])
print("}")

This produced code like

x509_attribute_type = {
"x509_attr_unknown" : 0,
"x509_attr_name" : 1,
"x509_attr_surname" : 2,
"x509_attr_givenName" : 3,
"x509_attr_initials" : 4,
...
}

You can do more advanced things if you want to, for example create structures for Python Struct (struct — Interpret bytes as packed binary data) to build control blocks. With this you can pass in a dict of names, and the struct definitions, and it converts the bytes into the specified definitions ( int, char, byte etc) with the correct bigend/little-end processing etc.

Making WordPress code blocks display the right size

I started using WordPress’s block code with syntax highlighting. Unfortunately the text was being displayed too large.

What I wanted

x509_attribute_type = {
"x509_attr_unknown" : 0,
"x509_attr_name" : 1,
"x509_attr_surname" : 2,
"x509_attr_givenName" : 3,
"x509_attr_initials" : 4,
...
}

What I got

x509_attribute_type = {
"x509_attr_unknown" : 0,
"x509_attr_name" : 1,
"x509_attr_surname" : 2,
"x509_attr_givenName" : 3,
"x509_attr_initials" : 4,
...
}

There were “helpful” suggestions such as changing the CSS, but these did not work for me.
What did work (but involved several clicks) is

  • create a pre-formatted block
  • paste the data
  • in the FONT SIZE box on the right hand side click S
  • go back to your block, and make it into a code block
  • from the pull down list of languages, select the language you want
  • It should not display the code in the right sized font

What the above actions have done is to put <pre class=”wp-block-code has-small-font-size”></pre> around the code snippet, which is another solution.