That’s the scenario for my first workflow!

Changing location

I configured three network locations on my laptop, two for home and the last one for office setup; I can switch between locations using the network pane in System Preferences or via the Apple logo in the menu bar… but why don’t reach these settings via keyboard?

Since 2003, Macos comes with an handy command line utility called scselect: scselect provides access to the system configuration sets, commonly referred to as “locations”. When invoked with no arguments, scselect displays the names and associated identifiers for each defined “location” and indicates which is currently active. scselect also allows the user to select or change the active “location” by specifying its name or identifier.

Let’s see how it works.

1
2
3
4
5
6

unixo:~ unixo$ scselect
Defined sets include: (* == current set)
   697A0192-1617-4BBF-A9FB-96E724876608   (Automatic)
   BFA8697D-49B0-457C-8080-CD9E18337E3E   (Home (Wi-Fi))
   FCFEA5B9-DE9F-41FA-92BB-EEA054A00846   (Home (Thunderbolt))
 * 0F946EF4-B73C-4AE5-8883-8A765DB82D2F   (Office)

As we expects, without any paramters, scselect returned all the configured locations: each of them is represented by the tuple <ID, name>; the line marked with the star represents the currently active network location, “Office” in this case.

If you want to switch to a specific location, simply specify its ID as parameter and let scselect do the rest.

1
2

unixo:~ unixo$ scselect BFA8697D-49B0-457C-8080-CD9E18337E3E
CurrentSet updated to BFA8697D-49B0-457C-8080-CD9E18337E3E (Home (Wi-Fi))

The workflow

My workflow will be made up of three objects:

• scselect, without any arguments, will be used in the first block to get the list of all network location (or part of it)
• the second block would be executed by Alfred only if the user select the an entry from the result list
• the third and last one will notify the user if everything went fine.

The script filter

For a script filter (the first block in the above picture) to display an output in result list, Alfred expects at least a XML like this:

1
2
3
4
5
6
7
8
9

<items>
  <item uid="..." arg="...">
      <title>here goes the title of the item</title>
      <subtitle>and here the subtitle for a small description</subtitle>
  </item>
  <item>
      ...
  </item>
</items>

The first block, the script filter, will use scselect to display all configured locations, formatted in XML.

1
2
3
4
5
6
7
8
9
10

shopt -s nocasematch;
echo "<items>";

[ -z "{query}" ] && line=1 || line=0

scselect | grep -i "{query}" | \
  sed -Ee ${line}d -e 's/  \(/ /g' -e 's/)$//g' -e 's/^[ \*]+//g' | \
  sed -E 's/^([^ ]+) (.*)$/<item uid="\1" arg="\1"><title>\2<\/title><subtitle>Set "\2" as current location<\/subtitle><\/item>/g';

echo "</items>";

This would generate the folloing result:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<items>
  <item uid="697A0192-1617-4BBF-A9FB-96E724876608" arg="697A0192-1617-4BBF-A9FB-96E724876608">
      <title>Automatic</title>
      <subtitle>Set "Automatic" as current location</subtitle>
  </item>
  <item uid="BFA8697D-49B0-457C-8080-CD9E18337E3E" arg="BFA8697D-49B0-457C-8080-CD9E18337E3E">
      <title>Home (Wi-Fi)</title>
      <subtitle>Set "Home (Wi-Fi)" as current location</subtitle>
  </item>
  <item uid="FCFEA5B9-DE9F-41FA-92BB-EEA054A00846" arg="FCFEA5B9-DE9F-41FA-92BB-EEA054A00846">
      <title>Home (Thunderbolt)</title>
      <subtitle>Set "Home (Thunderbolt)" as current location</subtitle>
  </item>
  <item uid="0F946EF4-B73C-4AE5-8883-8A765DB82D2F" arg="0F946EF4-B73C-4AE5-8883-8A765DB82D2F">
      <title>Office</title>
      <subtitle>Set "Office" as current location</subtitle>
  </item>
</items>

Each location is represented by an <item> entry: if the user selects a specific location, its ID will be extracted from the property UID of the item: this will be the input for the second block.

Run script

The second script is invoked only if user didn’t abort the operation and selected something.

1

scselect "{query}"

The query variable will be filled by Alfred with the UID of the selected item.

Post notification

Yay, you changed the location, let Alfred notify the user.

You can download the workflow here.

The following piece of code shows one of the entity.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

namespace AppBundle\Entity;

use Doctrine\ORM\Mapping AS ORM;

/**
 * @ORM\Entity
 * @ORM\Table()
 */
class Archetype {

  ...
      
    /**
     * @var array
     * @ORM\Column(type="json_array", nullable=true)
     */
    private $attributes;
  
  ...
}  

Of course this feature comes with a little of logic to be implemented, so that controllers and repositories can use them:

1
2
3
4
5
6
7
8
9

public function setAttribute($name, $value, $exposed = true) { ... }

public function setAttributes($attributes) { ... }

public function getAttributes() { ... }

public function getAttribute($key) { ... }

public function hasAttribute($key) { ... }

Instead of duplicating all these methods in each entity class, I found that PHP’s traits offers a good and nice tradeoff.

Traits

As of PHP 5.4.0, PHP implements a method of code reuse called Traits. Traits are a mechanism for code reuse in single inheritance languages such as PHP. A Trait is intended to reduce some limitations of single inheritance by enabling a developer to reuse sets of methods freely in several independent classes living in different class hierarchies. The semantics of the combination of Traits and classes is defined in a way which reduces complexity, and avoids the typical problems associated with multiple inheritance and Mixins.

I created a trait called “AttributeTrait” in the same namespace of my entities and implemented in it the methods listed before.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

namespace AppBundle\Entity;

trait AttributeTrait {
  
    /**
     * @var array
     * @ORM\Column(type="json_array", nullable=true)
     */
    private $attributes;

    public function setAttribute($name, $value, $exposed = true) {
        $attribute = compact('value', 'exposed');
        $this->attributes[$name] = $attribute;
        return $this;
    }
  
  ...

The nice aspect is that, the traits and the class that uses it, are merged togheter, as they were a whole class: this means that Doctrine will create a table with all the properties declared in the entity class and those belonging to the traits. The $this reference points to the container class, the entity instance in this case, so no changes to the code should be made.

Accessing the property from Twig

To complete the picture and make it more flexible even inside a Twig templates, I also implemented the special method __call, to make the code more readable.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77

<?php

namespace AppBundle\Entity;

trait AttributeTrait {

    /**
     * @var array
     * @ORM\Column(type="json_array", nullable=true)
     */
    private $attributes;

    public function __call($name, $arguments) {
        $attributeName =  lcfirst(str_replace('get', '', trim($name)));
        if (array_key_exists($attributeName, $this->attributes)) {
            return $this->attributes[$attributeName]['value'];
        }

        throw new \BadMethodCallException(sprintf('Product has no "%s" attribute.', $attributeName));
    }

    /**
     * Add a new attribute
     * 
     * @param string $name
     * @param mixed $value
     * @param bool $exposed
     * @return container class
     */
    public function setAttribute($name, $value, $exposed = true) {
        $attribute = compact('value', 'exposed');
        $this->attributes[$name] = $attribute;
        return $this;
    }

    /**
     * Add a set of attributes
     * 
     * @param array $attributes
     * @return container class
     */
    public function setAttributes($attributes) {
        $this->attributes = $attributes;
        return $this;
    }

    /**
     * Get all the attributes
     * 
     * @return array|null
     */
    public function getAttributes() {
        return $this->attributes;
    }

    /**
     * Get a single attribute corresponding to the given key
     * 
     * @see __call
     * @param string $key
     * @return mixed
     */
    public function getAttribute($key) {
        return $this->attributes[$key]['value'];
    }

    /**
     * Returns true if instance has the given attribute set
     * 
     * @param string $key
     * @return boolean
     */
    public function hasAttribute($key) {
        return array_key_exists($key, $this->attributes);
    }

}

From within a Twig template, I could use the typical syntax instance.property.

For example:

1
2
3
4
5

<?php

$archetype = new Archetype();
$archetype->setAttribute('width', 25.4);
echo $archetype->getWidth(); // this will invoke __call

From within a Twig template:

1

<p>Width: {{ archetype.width }}</p>

The width property doesn’t exist in class Archetype, but was added as dynamic property with trait support; Twig will call the corresponding method getWidth which is intercepted from special method __call and converted in an attribute access.

I ain’t a perl-fan, for this kind of problem I prefer PHP as development tool, so I was looking for some rock-solid PHP-framework that was:

• object-oriented developed
• able to manage an authentication (basic, digest, …)
• capable to issue any HTTP method (GET, POST, DELETE, …)
• (possibly) managed by composer

Googling around I found Guzzle, which meets all my requirements, makes use of Symfony’s event dispatcher (which I used in the past) and it’s also used by other well-known realities such as Drupal and Goutte.

Guzzle is ready-to-use, easy to setup and integrate with your project; by the way I spent half an afternoon analyzing the following scenario.

In its first response, the server sets the cookie FOO and, after the client successfully authenticates (basic authentication), the server clears the cookie FOO (assigning an empty value), along with creating a new one (BAR). From this moment, all requests sent by the client must not include the cookie FOO, but only BAR.

The problem is that the empty cookie FOO contained in the second server response is correctly discarded by Guzzle as it’s considered invalid, but Guzzle doesn’t check if there is already a cookie with the same name in the cookie jar.

Introducing the patch.

You can find the source here, the unit test and the merged pull request.

Everything work fine, but deploying in production, I ran into this problem:

1
2
3

% app/console cache:clear --env=prod
Clearing the cache for the prod environment with debug false
PHP Fatal error:  Cannot redeclare class EnhancedProxy_.... on line 64

I spent a lot of time digging Google, the problem seems very hard to solve at its origin, but I found this simple workaround: without any further arguments, the cache:clear command also tries to warm-up the cache and it seems that causes the problem.

By splitting the two operations, everything worked (at least for me!).

1
2
3
4

% app/console cache:clear --env=prod --no-warmup
Clearing the cache for the prod environment with debug false
% app/console cache:warmup --env=prod
Warming up the cache for the prod environment with debug false

Hope this saves someone some time.

Here the pattern I chose for my application and the reasons why.

Problem description

First of all, my application runs under MacOS, it’s backed by CoreData and based on NSPersistentDocument, so my considerations and needs are strictly related to this context: the same problem would be addressed in a different way if it was under IOS or requirements were different.

In a subview of my application, user can drop one or more files into a drop view, for example dragging them from Finder; these files could be of different kind (images, documents, …) but must be all handled in the same way and, possibly, without any interaction with the user. The drop view, the receiver of dropping operation, will ask the import manager to handle these files, returning immediately and maintaining the UI responsive; the import manager should also be able to import files concurrently, abort one or more operations if user asked so.

The “Import Manager”

As different file types must be handled, there will be an importer for each of them and another one class to manage them all. The import manager creates an operation queue in which will enqueue the import operations: it will wait for the drop view to ask to import new resources and create as many operations as requested.

The method importItems:intoDocument of the importer manager is called by the drop view: it requires an array of items to import and the current document which will be the owner of newly created resources. Note that items is an array of DZImportItem, a wrapper class that represent a single file to import.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

@implementation DZImporterManager

- (void) importItems:(NSArray *)items intoDocument:(NSPersistentDocument *)aDocument
{
    dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0);

    dispatch_async(queue, ^{
        [items enumerateObjectsWithOptions:NSEnumerationConcurrent
                                usingBlock:^(DZImportItem *item, NSUInteger idx, BOOL *stop) {
                       // Search for a class handler for current file
                       DZImportOperation *operation = nil;
                       for (Class handlerClass in _importers) {
                           if ([handlerClass canOpenURL:item.url]) {
                               operation = [[handlerClass new] initWithItem:item
                                                                    context:aDocument.managedObjectContext];
                               break;
                           }
                       }
                       // If an handler was found, enqueue the import operation
                       if (operation) {
                           [_queue addOperation:operation];
                       } else {
                           DDLogError(@"No registered handler for %@", item.url);
                           [item setStatus:DZStatusAborted
                               withMessage:Localize(@"No registered handler for this file type")];
                       }
                   }];
    });
}

Using dispatch_async of GCD we ensure that this operation will be executed in background and not in the same queue of UI, without blocking it.

Each data importer is a subclass of NSOperation, its main method will do the job. The following example is responsible to import image files.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

@implementation DZImageImportOperation

+ (BOOL)canOpenURL:(NSURL *)anUrl;
{
    BOOL retValue = NO;
    NSString *uti;
    NSError *error;

    if ([anUrl getResourceValue:&uti forKey:NSURLTypeIdentifierKey error:&error]) {
        retValue = UTTypeConformsTo((__bridge CFStringRef)(uti), (__bridge CFStringRef) @"public.image");
    }

    return retValue;
}

- (id)initWithItem:(DZImportItem *)item context:(NSManagedObjectContext *)moc;
{
    if ((self = [super init])) {
        _importItem = item;
        _context = [moc createPrivateSubcontext]; /* we'll see later this method */
    }
    return self;
}

- (void)main
{
    [self.context performBlockAndWait:^{
        @autoreleasepool {
            // Create new managed objects in self.context 
          // (an instance of NSManagedObjectContext)
          
            [self saveContext];
        }
    }];
}

@end

The method canOpenURL checks if the given file conforms to UTI public.image, which identifies an image file, while its main performs the job of opening the file and creating a corresponding managed object in the context. The last operation is saving the context: we’ll see deeper this part.

Managed Object Contexts

The pattern I chose is nested managed object contexts: in this scenario, you create new contexts which are children of the document’s one; at this point all the managed objects created in child context are propagated to the parent whenever a save occurs.

Let’s see the required steps to use them.

As you already saw, the importer makes use of -[NSManagedObjectContext performBlockAndWait], which implies that the managed object context has an associated queue. By default, an application based on NSPersistentDocument creates a managed object context initialized with NSConfinementConcurrencyType, which specifies that the context will use the thread confinement pattern: trying to use perfomBlock with this concurrency type would rise an exception. We have to override this default initialization by rewriting -[NSPersistentDocument setManagedObjectContext:].

1
2
3
4
5
6
7
8
9
10

- (void)setManagedObjectContext:(NSManagedObjectContext *)managedObjectContext
{
    if (managedObjectContext.concurrencyType != NSMainQueueConcurrencyType) {
        NSManagedObjectContext *context = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType];
        context.persistentStoreCoordinator = managedObjectContext.persistentStoreCoordinator;
        [super setManagedObjectContext:context];
    } else {
        [super setManagedObjectContext:managedObjectContext];
    }
}

In this way we create a managed object context with concurrency type NSMainQueueConcurrencyType, which allows us to create subcontexts. The inizialization of each single NSOperation subclass creates a new subcontext which is set up as child of document main context: a category of NSManagedObjectContext makes available this method and init the context with NSPrivateQueueConcurrencyType so that it will be associated with a private dispatch queue and won’t block the main context.

1
2
3
4
5
6
7
8

- (NSManagedObjectContext*)createPrivateSubcontext
{
    NSManagedObjectContext* context = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
    context.parentContext = self;
    context.undoManager = nil;

    return context;
}

Note: in my case the import operation doesn’t ever read of any other existing objects of the parent context, i.e. doesn’t issue a fetch request: this kind of operation would block the parent context even if the request was issued by the child.

Considerations

From the performance point of view, it seems this isn’t the best approach as nested contexts waste a lot of time in reciprocal synchronization and do a lot of disk access; read this excellent article by Florian Kugler about this argument.

According to his measurement, the best solution is create another context which shares the same persistent store; by the way, under MacOS, it’s not unusual for an application to create a new document and working on it without having saved to disk, i.e. without a persistent store. In this scenario, I had a lot of problem and got very often this exception: “Object’s persistent store is not reachable from this NSManagedObjectContext’s coordinator”.

With nested context there is also no need to watch for context save notification and call mergeChangesFromContextDidSaveNotification.

Useful resources and links

• Apple’s doc: concurrency Support;
• objc.io: Great article about best practises;
• Magical Records: Fantastic CoreData helper.

Some days ago, I encountered another issue about view controllers which completely drove me crazy; in my application I’ve a left sidebar and a right subview based on selection of the first one: each time the user makes a selection, a new subview is loaded by an equivalent NSViewController and presented to the user.

As well as with NSWindowController I put some basic initialization in awakeFromNib method of NSViewController, to be sure that NIB was loaded and all IBOutlet connected. In particular, in a subview, I had something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

- (void) awakeFromNib
{
    /* NSArrayController sort descriptor setup */
  [self reloadItems];
}

- (void) reloadItems
{
    dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0);
    dispatch_queue_t main = dispatch_get_main_queue();

    dispatch_async(queue, ^{
        [_arrayController fetchWithRequest:nil merge:NO error:nil];

        dispatch_async(main, ^{
            [_tableview reloadData];
        });
    });
}

Occasionally I noticed that reloadItems was called twice (or more), even much time later after initialization. After a boring debug session, I realized that in that subview I also had a view-based NSTableview and the view controller was its datasource and delegate.

That’s means that there also is a method like this:

1
2
3
4
5
6
7
8
9
10

- (NSTableRowView *)tableView:(NSTableView *)tableView rowViewForRow:(NSInteger)row
{
    id result = nil;

    if (tableView == _tableview) {
        result = [[DZMyRowView alloc] initWithFrame:NSMakeRect(0, 0, 100, 100)];
    }

    return result;
}

Each time this table needs a new row, ask its delegate for an instance of NSTableRowView and this causes awakeFromNib to be called again!!

For (at least) this reason, it’s always better initialize NSViewController overriding loadView method or by updating your awakeFromNib like this:

1
2
3
4
5
6
7
8
9
10
11

- (void) awakeFromNib
{
    static BOOL alreadyInit = NO;

    if (!alreadyInit) {
      /* NSArrayController sort descriptor setup */
      [self reloadItems];
      
      alreadyInit = YES;
  }
}

Introducing Download History

Whenever you don’t want to mess with Terminal, command lines and sqlite, you can use this simple utility, called Download History. This tool just opens your quarantine log and shows its content in a more readable format, powered with search and a command to delete the content.

For each table item, the detail box shows:

• the internal ID that uniquely identifies the resource
• the date/time you downloaded the file
• the title of the page you visited
• the URL of the downloaded file
• the original URL you came from
• the sender’s name and email address (whenever you received an attachment with Mail.app)

You can download the program here (built for Mountain Lion) and browse its sources on Github.

As stated in bundle documentation, if you are using a HTTPS connection, you have to set these two headers in your response for compatibility with IE<9:

1
2

$response->headers->set('Pragma', 'public');
$response->headers->set('Cache-Control', 'maxage=1');

By the way, as I had to generate a lot of reports and, instead of adding these two more lines, I decided to write a response listener: let’s describe these two simple steps.

First of all create a new file named MSExcelListener.php and store under the Listener folder of your bundle. Here the content of the file.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

<?php
namespace replace-this-line-with-your-namespace;

use Symfony\Component\HttpKernel\HttpKernelInterface,
    Symfony\Component\HttpKernel\Event\FilterResponseEvent;

class MSExcelListener
{

    /**
     * Adds the headers to the response once it's created
     */
    public function onKernelResponse(FilterResponseEvent $event)
    {
        // Only master requests are handled
        if (HttpKernelInterface::MASTER_REQUEST !== $event->getRequestType()) {
            return;
        }

        // Check if response is serving an "vnd.ms-excel" file
        if (preg_match('/vnd.ms-excel/', $event->getResponse()->headers->get('Content-Type'))) {
            /** 
             * If you are using a https connection, you have to set those two 
             * headers for compatibility with IE <9
             */
            if (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off' || $_SERVER['SERVER_PORT'] == 443) {
                $response = $event->getResponse();
                $response->headers->set('Pragma', 'public');
                $response->headers->set('Cache-Control', 'maxage=1');
                $event->setResponse($response);
            }
        }
    }

}
?>

Next step is registering the listener, so that Symfony kernel calls it before the response is sent to the client: simply add these lines to your configuration (just like you register a new service):

1
2
3

<service id="listener_msexcel_tweak" class="<YourBundleName>\Listener\MSExcelListener" public="true">
  <tag name="kernel.event_listener" event="kernel.response" />
</service>

If the response content-type is a vnd.ms-excel file and the site is running over HTTP, the two headers are automatically added.

Main features:

• built-in support for Weblogic and JBoss<
• JNDI resources browsing
• automatic discovering of SQL datasource
• automatic loading of external libraries (JARs) to interact with AS
• interaction with SQL datasources
• easy to extend

Installation

To use ASExplorer you’ll need:

• a JAVA compiler (javac)
• a Java based make tool (ant)
• specific application server libraries

First of all, download the package and build it:

1
2
3
4

$ cd <path-to-asexplorer>
$ ant
$ cd dist
$ mkdir -p lib/ext

Copy all JAR files you need to connect to in this folder (lib/ext); in my testing environment, I use the following files:

• concurrent.jar
• cryptojFIPS.jar
• jboss-client.jar
• jboss-common-core.jar
• jboss-integration.jar
• jboss-jmx.jar
• jboss-logging-log4j.jar
• jboss-logging-spi.jar
• jboss-remoting.jar
• jboss-security-spi.jar
• jboss-serialization.jar
• jbossall-client.jar
• jbosscx-client.jar
• jbosssx-client.jar
• jnp-client.jar
• ojdbc14.jar
• webserviceclient+ssl.jar
• webserviceclient.jar
• wlcipher.jar
• wlfullclient.jar
• wls-api.jar
• wlthint3client.jar

Examples

Enumerate all JNDI resources exposed by application server

1
2
3
4
5
6
7
8

$ java -jar ASExplorer.jar --server localhost:1099 --type jboss --command browse
 |
 +- UserTransactionSessionFactory
 +- UUIDKeyGeneratorFactory
 +- MySqlDS
 +- SecureManagementView
 | +- remote-org.jboss.deployers.spi.management.ManagementView
 | +- remote

Automatic datasources enumeration

1
2
3

$ java -jar ASExplorer.jar --server localhost:1099 --type jboss --command enumds
Found 1 datasource(s)
MySqlDS - MySQL 5.5.13-log

Interaction with SQL datasources

Assuming that your application server is exporting an Oracle-based datasource named OracleDS:

1
2
3
4
5
6
7
8
9
10
11
12

$ java -jar ASExplorer.jar -s 127.0.0.1:7100 -t weblogic -c sql-select --sql 'SELECT * FROM session_privs' --datasource OracleDS
| PRIVILEGE 
| CREATE SESSION 
| UNLIMITED TABLESPACE 
| CREATE TABLE 
| CREATE CLUSTER 
| CREATE SEQUENCE 
| CREATE PROCEDURE 
| CREATE TRIGGER 
| CREATE TYPE 
| CREATE OPERATOR 
| CREATE INDEXTYPE

Parameters available:

Inspect a class with reflection

1

java -jar ASExplorer.jar --server localhost:1099 --type jboss --command inspect --class jmx/invoker

TODO

• complete log4j integration
• add GlassFish support
• support for DQL queries

Check it out at GitHub

Specifica del problema

Scrivere un programma multithread che consenta di valutare le performance, in termini di numero di page fault, di algoritmi di rimpiazzamento delle pagine per la gestione della memoria virtuale.

Il programma dovrà essere costituito da un’entità principale che operi come una Memory Management Unit (MMU), un numero arbitrario (n) di thread, ove ogni thread emuli un singolo processo (PROCESSO) e, infine, da un’entità che emuli un dispositivo di I/O (DISPOSITIVO I/O).

Il programma dovrà simulare una sessione di lavoro, nella quale sono presenti n processi che possono accedere alla memoria e generare richieste di I/O. I processi dovranno generare indirizzi di memoria casuali. Infine, il programma terminerà una volta raggiunto il numero prestabilito di accessi in memoria totali.

MMU

L’entità MMU sarà la base del sistema ed utilizzerà l’algoritmo di rimpiazzamento delle pagine oggetto di test. Essa dovrà essere istanziata dal thread principale (main) e sarà gestita come oggetto condiviso tra i diversi thread dei PROCESSI. In particolare essa definirà la dimensione dello spazio di indirizzamento virtuale, la dimensione della memoria fisica disponibile e la dimensione della pagina.

La MMU dovrà, inoltre, contenere una lista di tabelle della pagine ciascuna relativa ad un PROCESSO. La definizione della specifica delle tabelle delle pagine sarà lasciata allo studente, e naturalmente dipenderà dal particolare algoritmo di rimpiazza mento implementato.

I PROCESSI dovranno generare indirizzi verso la MMU invocandone un metodo pubblico.

L’accesso a tale metodo dovrà garantire la mutua esclusione (un solo PROCESSO alla volta potrà invocare il suddetto metodo. La mutua esclusione dovrà essere ottenuta utilizzando le primitive di sincronizzazione messe a disposizione dal linguaggio di programmazione eccezion fatta per il costrutto monitor (per chiarezza, ad esempio, in java non sarà possibile utilizzare il costrutto synchronized).

Il metodo in questione processerà la richiesta andando ad interrogare l’opportuna tabella delle pagine. Nel caso in cui, l’indirizzo generato sia relativo ad una pagina già mappata in memoria la MMU si limiterà ad incrementare un contatore statistico di page hit. D’altra parte, nel caso in cui l’indirizzo generato dal PROCESSO faccia riferimento ad un indirizzo contenuto in una pagina non mappata in memoria la MMU dovrà eseguire i seguenti passi:

• incrementare un contatore di page fault
• selezionare una pagina mappata da rimuovere (vittima) secondo la politica dell’algoritmo oggetto di test
• aggiornare le opportune tabelle delle pagine
• indicare come non valida la pagina che è appena stata rimossa
• inserire una nuova entry nella tabella delle pagine del PROCESSO che ha generato il page fault (la pagina è stata appena caricata).

PROCESSO

L’entità PROCESSO dovrà emulare un processo in esecuzione su di un sistema multi programmato. Ogni processo dovrà essere emulato attraverso l’utilizzo di un singolo thread. Lo scheduling dei thread sarà delegato alle librerie messe a disposizione dal linguaggio di programmazione (configurazione default).

Il comportamento di ogni PROCESSO può essere descritto da una macchina a stati finiti comprendente due soli stati mutuamente esclusivi:

• Richiesta indirizzo di memoria (invocazione del metodo pubblico della MMU);
• Richiesta operazione di I/O (invocazione del metodo pubblico del DISPOSITIVO di I/O).

Le transizioni tra i due stati dovranno essere gestire in maniera probabilistica. In particolare, dovrà essere definita una probabilità p (input fornito al momento del lancio dell’applicazione) di generare indirizzi di memoria (“entrare nello stato a dato che ci si trovava nello stato b” = “rimanere nello stato a”) e una probabilità q = 1-p di generare richieste di I/O (“entrare nello stato b dato che ci si trovava nello stato a” = “rimanere nello stato b”).

I PROCESSI dovranno prevedere la possibilità di essere inizializzati con diversi valori di probabilità p.

DISPOSITIVO di I/O

L’entità DISPOSITIVO di I/O dovrà essere gestita come un ulteriore thread. Questa avrà un metodo pubblico attraverso il quale i PROCESSI potranno effettuare una richiesta di I/O.

Le richieste di I/O dovranno essere gestite con un coda di tipo FIFO. Le richieste saranno, ovviamente, bloccanti, mettendo il PROCESSO chiamante in uno stato di attesa fino al soddisfacimento della richiesta.

Il DISPOSITIVO di I/O determinerà il tempo di servizio di ciascuna richiesta in modo casuale estraendo a caso un valore intero, espresso in millisecondi, compreso fra Tmin e Tmax (parametri di inizializzazione del DISPOSITIVO di I/O).

Dati di INPUT

Il programma dovrà ricevere in input i seguenti parametri di inizializzazione:

• Numero di PROCESSI
• Probabilità p di generare accessi in memoria (una p per ogni PROCESSO; la probabilità di accedere al dispositivo di I/O sarà pari a 1-p);
• Tempi di servizio minimi e massimi del DISPOSITIVO di I/O (Tmin e Tmax);
• Numero totale di accessi in memoria raggiunto il quale il programma dovrà terminare.

Dati di OUTPUT

Al termine della simulazione il programma dovrà stampare a video la percentuale di page fault totale (relativa a tutti i processi), la percentuale di page fault relativa a ciascun PROCESSO, il tempo medio di servizio del DISPOSITIVO di I/O ed il tempo medio di attesa per una richiesta di I/O relativo a ciascun PROCESSO.

Ciascun PROCESSO dovrà scrivere in un proprio file di log la successione di indirizzi generata e le chiamate al dispositivo di I/O.

Analisi del problema

Il problema richiede di realizzare un simulatore elementare di memoria virtuale, utile all’analisi del comportamento e relative prestazioni di un algoritmo di rimpiazzo delle pagine. Il sistema realizzato simulerà un ambiente di lavoro multi programmato, nel quale operano più processi contemporaneamente.

Un’analisi iniziale ci suggerisce che questo problema sia di tipo decidibile, ovvero presuppone l’esistenza di un algoritmo che lo risolva in tempo finito e per una qualunque istanza di dati, espressa in termini di numero di processi contemporanei, dimensione della pagina e così via.

Come da specifica, il simulatore non avrà bisogno di alcun dato di ingresso per funzionare. Un insieme esteso di parametri da riga di comando permetterà di alterare alcuni aspetti e funzionalità del simulatore.

L’output del programma sarà costituito da alcuni dati statistici, prodotti a seguito del numero prestabilito di accessi alla memoria.

Progettazione dell’algoritmo

La scelta della struttura dati e del relativo algoritmo tiene conto dei parametri dettati dalla specifica del problema: l’attenzione sarà dunque focalizzata sulla politica di rimpiazzo delle pagine, sulle strutture dati necessarie ed sullo scenario che tali scelte determinano; l’analisi non terrà quindi in considerazione l’impatto che il paging nella memoria secondaria possa avere sull’efficienza complessiva del sistema, né dei tempi d’accesso alla memoria o di caricamento di una pagina.

Si è scelto di articolare il programma in tre fasi distinte:

1. analisi dei parametri forniti su riga di comando: di particolare rilievo, la possibilità di modificare alcuni parametri di funzionamento del simulatore;
2. inizializzazione delle strutture dati e successiva esecuzione dei singoli thread;
3. attesa del completamento dei thread, relativa deallocazione delle strutture dati e successiva stampa delle statistiche.

Descrizione del simulatore

Un sistema dotato del meccanismo di memoria virtuale consente ad un processo di allocare una quantità di memoria superiore a quella effettivamente disponibile. La tecnica si basa sull’utilizzo di altri tipi di memoria, detta secondaria, che entrano in gioco quando la memoria fisica risulta piena. Il meccanismo di memoria virtuale implementato per il simulatore è quello della paginazione.

La paginazione prevede la suddivisione della memoria fisica in frame, tutti della stessa dimensione; analogamente, anche la memoria allocata da un processo viene diviso in pagine, la cui dimensione è pari a quella di un frame di memoria fisica: tale suddivisione avviene ad opera della mmu, in modo totalmente trasparente al processo utente.

Al pari di un sistema operativo, il simulatore terrà aggiornata una tabella dei processi attivi: ogni voce nella tabella è rappresentativa di un processo e delle pagine virtuali allocate.

Per semplicità, si suppone che la tabella dei processi e la relativa page table siano sempre residenti in memoria, ovvero che queste non vengano mai paginate a loro volta.

Perché un processo possa accedere ad un’informazione contenuta in una determinata pagina virtuale, è necessario che quest’ultima sia presente nella memoria fisica ovvero, nello specifico, che sia associata ad un frame. Quando la lista dei frame disponibili non è esaurita, sarà sufficiente associare la pagina richiesta ad un frame disponibile; nel caso contrario, si dovrà applicare una politica di rimpiazzo delle pagine, volta a selezionare una pagina tra quelle presenti in memoria, spostarla nella memoria secondaria e associare il frame appena liberato alla pagina richiesta.

L’algoritmo di rimpiazzo delle pagine scelto è l’enhanced second chance, noto anche come algoritmo dell’orologio: tale soluzione nasce come una naturale evoluzione della tecnica FIFO, superando il problema di rimuovere le pagine usate più di frequente.

La realizzazione di tale algoritmo impone che ogni pagina contenuta nella page table del processo, oltre le comuni informazioni, debba contenere due ulteriori bit:

• bit reference ( R): verrà posto al valore uno (1) quando si accederà alla pagina in questione, sia in scrittura che lettura: tale informazione permetterà di sapere se ad una pagina presente in memoria si sia acceduto di recente o meno;
• bit dirty (D): verrà posto ad uno (1) quando si accederà alla pagina  in scrittura: quando una pagina dovrà essere rimossa dalla memoria, il valore uno di questo bit suggerirà al sistema operativo di fare una copia della pagina nella memoria secondaria, prima della rimozione dalla memoria principale.

La ricerca della pagina virtuale da rimuovere dovrà tenere conto delle quattro possibili combinazioni ottenute con questi due bit:

La ricerca della pagina migliore non solo si traduce nella selezione della pagina non usata di recente, ma anche di quella che non sia stata modificata. In questo modo, le pagine utilizzate più di frequente hanno alta probabilità di rimanere nella memoria principale, a discapito delle pagine a cui si è acceduto meno frequentemente.

Quando una pagina presente in memoria risulta sporca, si dovranno quindi effettuare due operazioni di I/O: il primo accesso alla memoria secondaria sarà necessario per effettuare il page out, ovvero copiare la pagina sporca sul disco, mentre una seconda operazione di lettura sarà necessaria per il page in della pagina che ha generato il fault. In questo scenario, l’algoritmo scelto, analizzando periodicamente le pagine che risultano sporche e provvedendo ad un preventivo write back nella memoria secondaria, migliora sensibilmente le prestazioni complessive, nonché il tempo medio d’accesso alla memoria.

Tale algoritmo, tuttavia, ha lo svantaggio di partizionare l’insieme delle pagine in due classi: quelle usate di recente e quelle usate con minor frequenza; quando termina la ricerca per il rimpiazzo, non è detto che la pagina identificata sia la più vecchia in assoluto, ma semplicemente una delle pagine meno utilizzate di recente.

Il caso migliore si verifica quando il primo frame analizzato ha i bit R e D posti a zero: la ricerca termina immediatamente e non sarà nemmeno necessaria un’operazione di I/O volta a fare una copia della pagina nella memoria secondaria.

Come da requisito, i processi effettuano soltanto l’operazione di lettura della memoria: è tuttavia possibile alterare questo comportamento specificando il parametro “–w” da riga di comando, per ottenere una simulazione che prevede l’uso del bit dirty.

Il caso peggiore dell’enhanced second chance si verifica quando tutte le pagine residenti in memoria sono sia referenziate che modificate: in questo caso, l’MMU dovrà necessariamente scorrere interamente la lista delle pagine presenti, ottenendo la medesima complessità dell’algoritmo FIFO.

Da tali considerazioni, è facilmente comprensibile che la complessità dell’algoritmo sia O(n), ovvero lineare e proporzionale al numero di frame in cui è stata suddivisa la memoria.

Non meno importante è sottolineare che, essendo un’evoluzione della tecnica FIFO, tale approccio soffre dell’anomalia di Belady (si veda a tal proposito il test 7).

Nei sistemi moderni, alcune funzionalità utili all’implementazione di tale algoritmo vengono implementate direttamente dall’hardware, quale, ad esempio, l’impostazione ad uno del bit reference e dirty ogni qualvolta una pagina venga referenziata o modificata.

Un algoritmo di rimpiazzo può essere di tipo locale o globale: il simulatore proposto effettua una ricerca globale, ovvero quando avviene un page fault, l’MMU cercherà la pagina candidata alla rimozione dalla memoria tra le pagine di tutti i processi attivi e non limitandosi alle pagine allocate del processo corrente. Sebbene una ricerca locale prevenga influenze da parte degli altri processi in termini di page fault, un algoritmo globale risulta complessivamente più efficiente nonché più semplice da implementare.

La modalità di generazione degli indirizzi, ad opera dei processi utente, è in linea con il principio di località, secondo cui se la CPU sta accedendo ad uno specifico dato (o istruzione), con molta probabilità i prossimi dati (o istruzioni) saranno ubicati nelle vicinanze di quella in corso: valutare tale principio ed i suoi impatti è di fondamentale importanza per il funzionamento e le prestazioni della memoria virtuale gerarchica dei moderni sistemi.

È stato, in ultimo, scelto un approccio di tipo pure demand paging, il quale prevede di non assegnare alcun frame al processo fintanto che la pagina non venga referenziata.

I vantaggi di tale tecnica sono immediatamente percepibili:

• le pagine inutilizzate non vengono mai caricate in memoria, aumentando la quantità di memoria disponibile ad altri processi;
• all’avvio di un programma, viene ridotta la latenza necessaria a caricare le pagine in memoria;
• minor carico di I/O dovuto ad un minor numero di pagine da caricare.

In presenza di un sistema con poca memoria fisica disponibile, il demand paging assicura un grado più elevato di concorrenza di processi.

Per semplicità, si è assunto che le pagine contenenti le istruzioni del processo siano sempre residenti in memoria: soltanto le pagine contenenti dati verranno gestite dalla MMU e dalla suddetta politica di rimpiazzo.

Il sistema emulato farà uso di indirizzi a 20 bit: da un punto di vista fisico, un simile spazio di indirizzamento consente di gestire una memoria fisica composta, al massimo, da 1,048,576 byte: il simulatore sarà appunto dotato di questo quantitativo, sebbene sia possibile alterare tale aspetto con l’opportuno parametro da riga di comando (-R).

Anche i processi utente utilizzano un indirizzamento a 20 bit; lo spazio d’indirizzamento virtuale sarà ovviamente superiore a quello fisico in quanto si dovrà considerare anche la memoria secondaria. Sono dunque possibili due scenari che, in assenza del meccanismo di memoria virtuale, non potrebbero sussistere:

• più processi contemporanei, ognuno dei quali alloca il massimo della memoria fisica: la somma di tutti gli spazi d’indirizzamento risulta maggiore della memoria fisica;
• un sistema dotato di una quantità ridotta di memoria fisica ma che consente ugualmente ad un processo di allocare 1Mb di memoria virtuale.

Un indirizzo virtuale a 20 bit generato da un processo sarà suddiviso, in modo del tutto trasparente, in due parti distinte: i otto bit più significativi (da 19° al 12°) verranno usati come indice per consultare la page table del processo, mentre i restanti dodici bit rappresenteranno l’offset da sommare all’indirizzo di partenza del frame associato.

Una simile suddivisione consente ad ogni processo di allocare un massimo di 256 pagine virtuali (2⁸), la cui dimensione è pari a 4,096 byte (2¹²): ovviamente il numero di pagine virtuali disponibili per un processo è indipendente dal numero di frame disponibili. Qualora il rapporto tra i frame disponibili ed il numero massimo di processi concorrenti risulti vantaggioso, il programma attiverà automaticamente la paginazione anticipata: l’MMU, infatti, non si limiterà a caricare in memoria la pagina mancante, causa del fault, ma anche un ristretto numero di pagine adiacenti. In pratica il simulatore cerca di prevedere quali pagine saranno richieste in virtù della località dei dati e le carica prima di quando queste vengano effettivamente richieste.

La suddetta funzionalità è da considerarsi puramente dimostrativa ed embrionale.

Di seguito vengono riassunte le scelte progettuali che caratterizzano il simulatore.

Descrizione moduli

Di seguito verranno descritti,  con maggiore dettaglio, gli aspetti implementativi dei singoli moduli: l’MMU, il dispositivo di I/O ed il processo.

Ogni singolo modulo del simulatore viene inizializzato direttamente dal main() attraverso le rispettive funzioni e sulla base dei parametri specificati da riga di comando. Terminata questa fase, inizierà l’interazione tra i singoli thread.

Memory Management Unit (MMU)

Il thread che emula l’MMU è il primo ad essere istanziato dal simulatore, direttamente all’interno del main: questo si occupa della traduzione di un indirizzo virtuale, generato da un processo, in un equivalente indirizzo fisico di memoria.

La funzione mmu_init è incaricata di configurare l’ambiente del simulatore nonché di partizionare la memoria fisica in frame. Ad ogni frame verranno associate le seguenti informazioni:

• id: tale valore identifica univocamente un frame;
• physical_addr: questa variabile conterrà l’indirizzo di memoria fisica di partenza del frame; durante il ciclo di vita del simulatore, la lista dei frame non sarà ordinata per id: questo è il valore di base cui sommare l’offset dell’indirizzo virtuale;
• valid: il bit verrà posto ad uno (1) quando il frame è utilizzato;

Ad ogni frame vengono inoltre associate due ulteriori campi, pid e page_id: sebbene non siano necessari al funzionamento del simulatore, hanno il solo scopo di rendere più semplice il debug, nonché offrono la possibilità di mantenere un’associazione frame –> processo –> pagina.

L’MMU fa uso di due liste semplici: la prima, free_frames, per tenere traccia dei frame liberi (ovvero non associati ad alcuna pagina) ed used_frames per i frame utilizzati. Terminata l’inizializzazione della memoria, tutti i frame saranno presenti nella lista free_frames, condizione dettata dal demand paging. Un’ulteriore lista, active_pages, conterrà solo le pagine presenti in memoria.

La funzione thread_mmu viene eseguita come thread e simula l’MMU: l’interazione tra questo thread ed i processi è resa possibile dalla funzione memory_read, invocata direttamente dai processi che tentano un accesso alla memoria. Quest’ultima si occuperà di inserire in una struttura temporanea i dati relativi al processo chiamante, nonché l’indirizzo virtuale richiesto e segnalerà alla MMU la presenza di una richiesta; l’MMU, nel vagliare la richiesta, sceglierà quale frame associare alla pagina equivalente ed, al termine, restituirà l’indirizzo di memoria fisico.

Di seguito verrà illustrato lo schema a blocchi del funzionamento della MMU.

L’algoritmo enhanced second chance viene applicato solo quando la pagina richiesta non è presente in memoria ed, al contempo, tutti i frame risultano occupati. Ha quindi inizio una ricerca della pagina candidata alla rimozione: i due bit precedentemente descritti, reference e dirty, tengono traccia dell’uso e della modifica delle pagine.

L’algoritmo prevede che l’elenco delle pagine utilizzate sia rappresentato da una lista circolare, mentre è stata usata una lista doppiamente concatenata che, nel caso peggiore, viene visitata per intero.

Processo

La funzione thread_proc, eseguita come thread, si occupa di simulare un processo utente.

La rappresentazione in memoria del singolo processo, nonché delle caratteristiche che lo contraddistinguono, è affidata alla struttura proc. Avendo come riferimento un sistema operativo reale, al proprio interno, il simulatore gestisce una lista di tutti i processi attivi, detta process table: ogni voce in questa tabella è di tipo proc e contiene le seguenti informazioni:

• pid: identificativo univoco del processo;
• tid: identificativo univoco del thread che simula il processo;
• page_count: numero di pagine virtuali allocate dal processo;
• page_table: tabella delle pagine del processo; questa informazione non deve essere accessibile al processo;
• percentile: probabilità del processo di effettuare un accesso alla memoria piuttosto che al dispositivo di I/O;
• io_cond/io_lock: condizione e relativo mutex nel quale il thread resta in attesa di completamento di una richiesta di I/O;
• log_file: file di log del processo;
• proc_stats: struttura per contenere le statistiche d’accesso del processo.

Nei sistemi reali, un processo ha visibilità solo di alcune informazioni contenute nella process table o relative al sistema ospite: per esempio, un processo potrà sapere qual è il proprio pid o la dimensione della memoria virtuale, ma non potrà tuttavia accedere alla lista delle pagine o dei frame, informazioni ad unico appannaggio del sistema operativo. Seguendo le implementazioni dei più comuni sistemi nix si è dunque scelto di non far gestire alla mmu la tabella delle pagine virtuali del processo, garantendo opportunamente la protezione dello spazio d’indirizzamento: l’mmu farà piuttosto uso di una propria struttura dati per gestire l’associazione delle pagine ai frame. Questa scelta trova ulteriore giustificazione nel fatto che ogni processo può allocare una quantità variabile di memoria e l’mmu, che viene inizializzata prima della process table*, non può conoscere a priori tale quantità.

Poiché il simulatore non è stato implementato con un linguaggio orientato ad oggetti quale Java o C++, le API di accesso alla memoria ed al dispositivo di I/O devono contenere necessariamente l’identificativo del richiedente, nello specifico il pid.

La funzione proc_init ha il compito di creare n istanze del thread processo, per ognuno dei quali associa un numero casuale di pagine virtuali.

Il numero casuale di pagine virtuali è compreso tra 1 e 256, in modo tale che tutti i processi abbiano almeno una pagina associata e comunque non superiore al limite massimo di 256. È tuttavia possibile massimizzare tale valore per tutti i processi usando il parametro –M.

La funzione thread_proc, si occupa di scegliere se effettuare un accesso alla memoria o al dispositivo di I/O, scegliendo tra le due operazioni con una probabilità impostata dall’utente: quando la funzione memory_access, utilizzata per accedere alla memoria, restituirà il valore -1, i processi termineranno la propria esecuzione.

L’accesso in memoria osserva il principio di località, secondo cui:

• se accedo ad un dato, probabilmente accederò anche a quelli vicini in un tempo non lontano (località spaziale);
• se accedo ad un dato è probabile che debba accedervi nuovamente in breve tempo (località temporale).

La realizzazione della località spaziale viene offerta dalla funzione simulate_loop che si occupa di simulare un accesso ad un vettore di n elementi: poiché in C gli elementi di un vettore occupano indirizzi di memoria contigui, simulare un accesso ad ognuno di essi coincide ad una località spaziale.

Quando il processo effettua invece un accesso pseudo casuale alla memoria, subentra la località temporale, ovvero la possibilità di accedere ad un dato recentemente utilizzato. In quest’ottica, il processo avrà il 30% di probabilità di accedere ad un indirizzo di memoria usato in precedenza.

Il parametro “–L” permette di variare la percentuale di località temporale, di default pari a 30%; ponendo uguale a zero tale valore, si elimina l’effetto di località.

L’operazione di lettura merita ulteriori considerazioni:

1. nel caso di accesso alla memoria, l’indirizzo virtuale è generato casualmente, ma è sempre compreso nello spazio d’indirizzamento virtuale del processo: qualora l’indirizzo fuoriuscisse da tale spazio, il simulatore avrebbe il compito di generare un fault e terminare il processo;
2. per una migliore simulazione dell’algoritmo scelto, che prevede l’uso del bit dirty, è stata implementata l’operazione di scrittura in una zona di memoria: la funzione che realizza tale operazione è sempre memory_access ma con il parametro rw posto ad uno; non sarà tuttavia presente un parametro utile a rappresentare l’informazione da scrivere in memoria, in quanto esula lo scopo della presente analisi;
3. per entrambe le tipologie di accesso, alla memoria od al dispositivo di I/O, il processo non ha visibilità diretta dei rispettivi thread: la possibilità di effettuare una richiesta viene offerta dall’uso di due funzioni pubbliche che svolgono il ruolo di intermediario.

Sussiste una sottile differenza tra i due tipi di accesso che un processo utente può effettuare: l’MMU rappresenta un oggetto condiviso tra più processi e può assolvere una richiesta per volta; se n processi tentassero l’accesso alla memoria, soltanto uno riuscirà nell’intento mentre gli altri “n-1” processi restano in attesa (mutua esclusione).

Di contro, l’accesso al dispositivo di I/O prevede che effettuare una richiesta d’accesso non sia bloccante, per cui se n processi tentassero l’accesso al dispositivo, tutti quanti riuscirebbero ad inserire la propria richiesta in coda: l’attesa avviene immediatamente dopo, non bloccando quindi gli altri attori della contesa, ma solo il processo che attende il risultato.

Di seguito viene illustrato il diagramma a blocchi del funzionamento del thread processo.

La prima condizione, uscita, viene soddisfatta quando la MMU ha effettuato il numero richiesto di accessi.

Dispositivo di I/O

Il dispositivo di I/O viene emulato dalla funzione thread_io_device, anch’essa eseguita come thread. Questo viene inizializzato ed istanziato immediatamente dopo aver creato il sottostrato di memoria virtuale.

Il funzionamento del dispositivo di I/O, a differenza della MMU, si basa su una lista di tipo FIFO: i processi che effettuano una richiesta a tale dispositivo vengono inseriti in coda e serviti in modo sequenziale. La richiesta è di tipo bloccante: un processo, in attesa che la richiesta venga soddisfatta, non può effettuare altre operazioni.

La funzione io_device_read rappresenta il metodo pubblico per inserire una richiesta in coda, al pari di memory_access per le lettura in memoria.

La coda di richieste di I/O costituisce una risorsa condivisa tra il thread (lettore) e la funzione io_device_read (scrittore) ed, in tal senso, l’accesso alla FIFO va gestito all’interno di una sezione critica: il mutex fifo_lock viene utilizzato dalle due entità al fine di mantenere coerente lo stato delle richieste.

Il thread terminerà la propria esecuzione su richiesta dell’MMU, quando questa avrà espletato il numero di richieste previsto.

Di seguito viene illustrato il diagramma a blocchi del dispositivo.

Come da specifica, il dispositivo viene configurato con due parametri, Tmin e Tmax, rispettivamente il tempo minimo e massimo perché una richiesta di lettura venga effettuata; il thread, una volta esaminata la richiesta, si occuperà di generare un numero casuale compreso in tale intervallo ed infine segnalerà al processo l’avvenuta operazione: il processo sarà nuovamente libero di effettuare altre operazioni con le modalità precedentemente descritte.

Prima fase: analisi dei parametri

Il programma inizierà la propria esecuzione analizzando i parametri specificati su riga di comando; sebbene questi non siano necessari per il funzionamento del simulatore, è disponibile un insieme di parametri per modificare alcuni comportamenti predefiniti dell’applicativo.

Di seguito vengono riassunti i possibili parametri:

Seconda fase: inizializzazione ed esecuzione thread

La corretta analisi dei parametri specificati su riga di comando permette di passare alla inizializzazione delle singole strutture dati ed all’esecuzione dei thread finora descritti.

La prima entità istanziata è appunto l’MMU, seguita successivamente dalla creazione del thread per il dispositivo di I/O ed in ultimo dai thread che simulano i processi utente.

Terza fase: stampa dei risultati

La terza fase ha inizio quando i processi utente hanno effettuato il  numero massimo di accessi alla memoria: questa condizione determina la fine di tutti i thread istanziati, siano essi utente, MMU o del dispositivo di I/O.

Una corretta conclusione prevede quindi di effettuare una pthread_join di tutti quanti i thread e la relativa deallocazione delle strutture dati fino a quel momento utilizzate.

Al termine di questa operazione, il simulatore si dovrà preoccupare di stampare a video le statistiche richieste. Oltre le suddette statistiche, saranno inoltre disponibili, nella directory di lavoro, i file di log di ogni singolo processo, all’interno dei quali si potrà trovare la lista delle operazioni effettuate dai processi utente.

Scarica l’intero progetto qui.

Problem specifications

The aim of this project is to realize an e-commerce tool, along with its database, for the final client who wishes to buy some product.

The first need is classifying technology products, such as computers, monitors, accessories and so on. To make products browsing easier, it is advisable to split items into categories, so that customers will be able to find what they’re looking for faster and easier; for each product it is known the id, the name and its description, as far as its price together with its availability.

Whenever a potential customer chooses an item from catalogue, the system should suggest a list of configurations containing the selected product: for example, if a laptop is chosen, the system will propose to buy some kind of mice or PCCARD which belong to the same configuration.

Only registered users are allowed to browse and buy items: for each user, it’s known the id, name and surname, together with his credential to access the system and a shipping address. A user must choose a unique login to be correctly registered.

A discount to total amount of customer order should be considered: total amount of an order could be different from the sum of each item. The system should allow the system administrator to delete an item from the catalogue: this operation must be permitted only under the condition that the selected item is not part of any previous orders, otherwise there must exist another way to hide the product from catalogue browsing and leave old orders consistent.

As the user runs the tool, he can register himself as a new user or log into the system by specifying his own credential. The interface must implement the following operations to read data:

• Browsing product catalog by category;
• Viewing details of the chosen product;
• Browsing all the configurations which include a given item;
• Browsing user’s profile and all the orders he made;
• Placing a new order.

The system should let the administrator issue the following operations, which may also alter data:

• Adding a new category;
• Adding a new product;
• Browsing proceeds of sales, grouped by month;
• Preventing a user from log in (lock);
• Deleting a product (even if it was already sold).

Download the project, along with the relation, the sources and database schema here.

I’ve already wrote the solution to this bug and soon I’ll release the new version which also includes a way to exclude person from sync.

Please, visit the following link: http://www.facebook.com/pages/YABI/

“This changes everything. Again.”

YABI core functions have been totally reimplemented and, above all, completed. This version addresses few bugs, which caused YABI Agent crashes (e.g. when an event name is changed in AddressBook).

I’ve also been asked for new interesting features, I’ll work on them in spare time:

• use remote calendar as target
• excluding birthdays
• enhanced nickname support

Upgrade note

We suggest to deactivate YABI before upgrading; follow these few steps:

• Open YABI preference pane
• Click on Deactivate button and quit System Preferences
• Upgrade YABI by double-clicking on the new icon

Download YABI at YABI.dmg and check it out!

Here some changes:

• [FIX] Nicknames were not properly imported by from Sync Server and it was impossible to substitute in event title
• [FIX] Target calendar change is now saved
• [FIX] Event title changes are properly saved
• [FIX] Alarm icon column is no more bound to “data” binding (“value” is now used: no more warning in your console about this deprecated construct)
• [NEW] Agent deactivation removes application data file
• [NEW] Deactivate button is now disabled when a fresh-sync is issued
• [NEW] Added the new specifier “%yp” (equal to %y minus 1)

Here what must still be implemented:

• Software autoupdate

Download YABI at YABI.dmg and check it out!

Here some changes:

• 64-bit enabled
• minor memory leaks fixed
• added “partner” attribute for anniversary cross-check
• UI updates
• removed unused frameworks

Here what must still be implemented:

• Save/restore event titles
• Software autoupdate

Download YABI at YABI.dmg and check it out!

DZSelectableBox is a subclass of NSBox view which emulates this behavior. An instance of this class comes with one more variable member, the box state: when the box is marked as selected, an inner rounded path is drawn inside its bounds; DZSelectableBox honors title position, if it’s visible. You can use this class in two different manners:  standalone or as part of a radio group.

Standalone version

A standalone box works as described before: the only thing you’ve to do is open Interface Builder, place a common NSBox in your window, change its class name into DZSelectableBox and start using it. You can change box state programmatically by using the toggleState message, the setSelected method to set its state or simply by clicking on it.

Radio group version

Whenever you need a group of boxes and the opportunity to select only one of them at time, you’ve to set a radio group; after you followed the steps described before to create your boxes, you’ve to add the following sample code to your application:

1
2
3
4

leftBox.radioGroup = [NSNumber numberWithInt:1];
rightBox.radioGroup = [NSNumber numberWithInt:1];
[leftBox setSelected:YES];
[rightBox setSelected:NO];

(we suppose you created two boxes and connected them to two outlets called leftBox  and rightBox)

When a box belongs to a radio group, it listens for group changes notification: for example, if you select the right box (by clicking on it), the left one will be automatically unselected.

Code is available on GitHubg

if you have this problem, follow these steps:

1. Go to the theme directory (DOC_ROOT/wp-contents/themes/yourtheme)
2. Look for file named single.php
3. Look for the template tag named the_content
4. Add a new line below and attach the following istructions:

<?php wp_link_pages(array(‘before’ => ‘<p><strong>Pages:</strong> ’,‘after’ => ‘</p>’, ‘next_or_number’ => ‘number’)); ?>

Try to reload the single post page and enjoy page-links.

For further informations about page-links, read this document.

Specifica del problema

Sia dato un semplice database che rappresenta un elenco di studenti che hanno sostenuto un esame.

Il database è organizzato sotto forma di file di testo su 3 colonne contenenti informazioni relative a (Cognome, Matricola, Voto) come ad esempio:

Scrivere un programma ANSI C che acquisisce il database da file, ne effettua un ordinamento in base alla chiave primaria (Cognome) o alle chiavi secondarie (Matricola, Voto) sulla base della scelta dell’utente e produce in uscita il database ordinato. L’ordinamento sulle chiavi secondarie deve conservare l’ordine relativo prodotto dalla chiave primaria.

Analisi del problema

Il problema richiede di ordinare una tabella mediante l’uso di un algoritmo stabile, ovvero un procedimento che, in presenza di più chiavi di ordinamento, preservi l’ordine relativo prodotto da altre chiavi; è facilmente intuibile che il problema posto sia decidibile, ovvero che esiste un algoritmo che lo risolve in tempo finito e per una qualunque istanza di dati.

Come da specifica, il dato di ingresso per il programma è costituito da un file, quale rappresentazione testuale della tabella del database; il programma impone che il formato del file sia CSV, ovvero delimitato da un determinato separatore di campo.

Per semplicità, si assume che il file sia sintatticamente corretto, ovvero che non esistano righe (record) che non abbiano i tre campi valorizzati correttamente.

L’output del programma sarà la medesima tabella, opportunamente formattata, ordinata secondo i criteri che l’utente potrà specificare da riga di comando, ed eventuali messaggi d’errore.

Progettazione dell’algoritmo

La scelta della struttura dati e del relativo algoritmo tiene conto dei parametri dettati dalla specifica del problema: l’efficacia dell’algoritmo di ordinamento sarà il parametro fondamentale per la scelta del modus operandi; l’analisi non terrà conto delle comuni problematiche relative alla gestione di una base dati, quale la gestione degli indici, un’efficiente gestione dello storage o la disponibilità del dato a fronte di crash applicativi.

Si è scelto di articolare il programma in tre fasi distinte:

* analisi dei parametri forniti su riga di comando: di particolare rilievo, la possibilità di definire un criterio di ordinamento; * lettura del file contenente i dati e relativa creazione della struttura dati in memoria; * stampa dei dati ordinati e successiva deallocazione della struttura dati.

Struttura dati

Al fine di risolvere il problema fornito in modo ottimale, si è scelto di adottare una struttura dati del tipo albero rosso nero, particolare evoluzione dell’albero binario.

La modalità di rappresentazione del dato in memoria non può essere affidata ad una struttura statica quale il vettore1: tale soluzione, infatti, risulterebbe inefficiente in termini computazionali, in quanto gli algoritmi di ordinamento di vettori sono caratterizzati, nel caso migliore, da una complessità pari a n·log(n); non è inoltre noto a priori il numero di record che il vettore dovrebbe contenere, il che renderebbe la soluzione poco flessibile e scalabile.

La struttura dati originale prevede l’uso di un particolare nodo chiamato “sentinella”, in modo tale che non esistano foglie e tutti i nodi puntino alla sentinella: l’implementazione proposta farà uso di un puntatore nullo piuttosto che allocare un nodo.

Algoritmo

Il metodo di ordinamento scelto è di tipo interno, in quanto il file da ordinare può essere contenuto in memoria: questo approccio permette di accedere direttamente ad un record generico della tabella, riducendo sensibilmente i tempi di ordinamento; al contrario, un ordinamento esterno prevede che i dati risiedano su disco e si possa accedere ad essi solo in modo sequenziale o al più per grandi blocchi.

Sebbene l’implementazione di un albero rosso-nero risulti complessa, questo offre un eccellente tempo di esecuzione anche nel caso peggiore. L’implementazione proposta segue il paradigma di massimizzare l’efficienza in termini temporali di esecuzione, a discapito di un maggiore utilizzo di memoria: questa scelta progettuale si basa sulla considerazione che il sistema operativo, sfruttando diverse tecniche di virtualizzazione e gestione della memoria di sistema, metta a disposizione di un programma in esecuzione un quantitativo di memoria praticamente illimitato, al contrario del fattore “tempo” che non può essere riutilizzato e condiviso. L’algoritmo di ordinamento proposto prevede di memorizzare il record della tabella all’interno di un nodo dell’albero: ne consegue che l’operazione di lettura del file, la relativa creazione dei nodi e l’inserimento degli stessi all’interno dell’albero, generi un albero perfettamente bilanciato ed ordinato secondo i criteri richiesti. Nella tabella seguente vengono riassunte le principali proprietà, in termini di efficienza di algoritmo:

Si fa riferimento ad un albero contenente “n” nodi. I suddetti valori rappresentano il caso peggiore che si può verificare.

Le operazioni di lettura su un albero rosso-nero non richiedono particolari considerazioni rispetto a quelle utilizzate per gli alberi binari di ricerca, poiché gli alberi rosso-neri sono una loro specializzazione.

Prima fase: analisi dei parametri

Il programma inizierà la sua esecuzione inizializzando le strutture dati e le variabili necessarie al suo funzionamento. Successivamente verranno analizzati i parametri specificati su riga di comando, necessari per definire il nome del file contenente la tabella, nonché per modificare alcuni comportamenti predefiniti dell’applicativo.

Seconda fase: lettura del file di input

La lettura del file di input corrisponde alla fase più rilevante dell’applicazione: durante questa fase, in corrispondenza di ogni record letto dal file, verrà creato un nuovo nodo ed effettuato un inserimento nell’albero, qualora questa operazione risulti possibile.

L’implementazione della struttura dati e delle funzioni necessarie al suo mantenimento costituiscono una parte statica ed immutabile del programma; al contrario, la funzione preposta al confronto di due nodi generici tiene conto dei criteri di ordinamento specificati dall’utente.

Si è scelto di creare tre funzioni differenti (compare_name, compare_mark e compare_registration) preposte al confronto di due generici nodi dell’albero, ognuna delle quali tiene conto di uno solo dei tre campi del record; un vettore di puntatori a funzione verrà opportunamente inizializzato durante la prima fase con queste tre funzioni, seguendo l’ordine specificato dai criteri di ordinamento indicati dall’utente; in ultimo, la funzione che dovrà effettuare il confronto tra due nodi dell’albero, scorrerà il vettore ed userà la sotto-funzione specifica.

Le funzioni di ordinamento sono necessarie per individuare il punto esatto dell’albero nel quale inserire il nuovo nodo; il risultato immediato di un inserimento o di una cancellazione può corrispondere ad una violazione di una delle quattro proprietà fondamentali dell’albero rosso-nero: ristabilire tali proprietà richiede un numero limitato di operazioni, che possono avere una complessità costante nel caso medio, logaritmica nel caso peggiore.

Terza fase: stampa dei risultati

La terza fase si limita ad una ricorsione sull’albero per stampare i nodi presenti ed a una successiva fase di deallocazione della struttura dati utilizzata. Va sottolineato che la visita ricorsiva dell’albero per la cancellazione di un nodo, è di tipo non lineare: non è pertanto possibile ottimizzare ulteriormente l’implementazione a meno di non perdere di leggibilità e semplicità di gestione del codice (al contrario, una ricorsione lineare potrebbe essere sostituita con un’iterazione, portando ad una riduzione della complessità).

Si è scelto di non implementare in forma iterativa la funzione “node_traverse”: sebbene questa forma risulti più efficiente, si vuole dare esempio di visita ricorsiva in ordine simmetrico e posticipato (node_dealloc).

Testing del programma

Unitamente ai sorgenti che compongono il progetto, sono stati inclusi anche alcuni file contenenti dati di esempio; questi rappresentano istanze di input con dimensioni differenti, di modo che sia possibile un test più esaustivo dello strumento proposto.

Di seguito verrà incluso qualche test significativo ed il relativo output del programma; i seguenti test sono stati effettuati usando questi parametri da riga di comando:

• -i file: Legge i dati dal file specificato
• -o output.txt: Scrive la tabella ordinata nel file specificato
• -s criterio: Criterio di ordinamento

Test 1. lettura da un file inesistente

1
2
3

./rb-sorter -i not-exist.txt
[INFO] Creazione struttura dati
[INFO] Lettura dati dal file 'not-exist.txt' [ERR ] impossibile aprire il file 'not-exist.txt'

Test 2. database di 15 linee, duplicati presenti

1
2
3
4
5
6
7
8
9

$ time ./rb-sorter -i database_15_linee.txt -o output.txt -s c+m+v [INFO] Creazione struttura dati
[INFO] Lettura dati dal file 'database_15_linee.txt'
[INFO] Record letti : 15
[INFO] Nodi inseriti: 15
[INFO] Scrittura risultati
[INFO] Distruzione struttura dati
real  0m0.005s
user  0m0.001s
sys   0m0.003s

Test 3. database con 1,7 milioni di linee, duplicati non presenti

1
2
3
4
5
6
7
8
9

$ time ./rb-sorter -i database_1.7M_linee.txt -o output.txt -s c+m+v [INFO] Creazione struttura dati
[INFO] Lettura dati dal file 'database_1.7M_linee.txt'
[INFO] Record letti : 1699062
[INFO] Nodi inseriti: 1699062
[INFO] Scrittura risultati
[INFO] Distruzione struttura dati
real  0m10.839s
user  0m8.470s
sys   0m0.665s

Valutazione della complessità del programma

Per calcolare il tempo di esecuzione del programma nonché l’ordine di grandezza della complessità, si è scelto di adoperare due approcci distinti: in prima istanza, utilizzando un metodo analitico e, successivamente, uno sperimentale.

Approccio analitico

Sono stati identificati, all’interno del codice, tre macro blocchi di istruzioni: ad ognuno di questi è stato associato un costo, calcolando dapprima il numero effettivo di passi base eseguiti e derivando in seguito la classe dell’ordine di grandezza. Il primo blocco, la funzione loadfile, legge i dati dal file contenente il database; facendo coincidere il numero di righe del file con il numero di nodi che possibilmente verranno inseriti nell’albero, possiamo esprimere l’intero costo del programma in funzione del numero di record letti. Il costo del suddetto blocco sarà equivalente al prodotto di n record per il costo della funzione di inserimento di un nodo nell’albero, ovvero O(log n). Il secondo ed il terzo blocco del programma equivalgono alla visita dell’intero albero per stamparne i nodi ed alla deallocazione della struttura dati: entrambi hanno una complessità proporzionale al numero di nodi (record) presenti nell’albero, quindi pari ad O(n).

Di seguito, il riepilogo di quanto esposto:

La complessità totale quindi è pari a 2×n + n×log n, assimilabile alla classe di complessità pseudo lineare T(n) = O(n×log n).

Approccio sperimentale

L’approccio empirico proposto si basa sulla misurazione dei tempi di esecuzione del programma, fornendo istanze di input progressivamente maggiori.

Per ogni istanza di input, il programma è stato eseguito più volte: si è quindi valutato e riportato il valore medio.

Mettendo in relazione il numero di record processati ed il numero di secondi impiegati, si è notato come l’andamento della complessità temporale (espressa in secondi) seguisse la curva espressa dalla complessità calcolata con l’approccio analitico.

Di seguito i valori rilevati e loro rappresentazione grafica.

Scarica il progetto rb-sorter.tar.gz

In computing, an arithmetic logic unit (ALU) is a digital circuit that performs arithmetic and logical operations. The ALU is a fundamental building block of the central processing unit (CPU) of a computer, and even the simplest microprocessors  contain one for purposes such as maintaining timers.

This project is an example of an ALU realized with Tkgate for university purposes. The following operators are implemented:

• adder
• multiplier
• divider
• left/right and circular shift

It works with 8-bit unsigned numbers.

Download ALU.tgz